| 1.1, d (??), 23:00, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +33 +/– | |
> В проприетарном TCP/IP стеке
Аж передёрнуло. Это ж надо так упарываться, что бы такое продвигать и на этом зарабатывать.
| | |
| |
| 2.8, Аноним (8), 23:21, 16/06/2020 [^] [^^] [^^^] [ответить]
| +25 +/– |
А кое-кто бредит, что проприетарщина - это сверхнадёжно, её же профи пишут.
| | |
| |
| 3.12, ilyafedin (ok), 23:52, 16/06/2020 [^] [^^] [^^^] [ответить]
| –36 +/– |
 Ничто не надежно на сишке/крестах, пока код пишут человки.
Учитывая, что до техсина еще далеко, то выход один - раст.
| | |
| |
| 4.36, bOOster (ok), 08:59, 17/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Я никак не пойму, толи те кто за РАСТ агитирует, они че реально верят что сам RUST боги программирования без ошибок чтоли пишут???
Или это просто от недостатка ума?
| | |
| |
| 5.39, ilyafedin (ok), 09:16, 17/06/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Я никак не пойму, толи те кто за РАСТ агитирует, они че
> реально верят что сам RUST боги программирования без ошибок чтоли пишут???
> Или это просто от недостатка ума?
Просто есть большая разница, когда у тебя весь язык дырявый и надо не забывать писать определнным способом, чтобы не получить уязвимость
И когда unsafe-код - лишь сабсет кода
Все уязвимости вряд ли получится убрать, но сутощественное их уменьшение - уже хороший результат.
| | |
| |
| 6.51, Cradle (?), 12:01, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
проблема раста к сожалению в том что вы конечно можете на нем написать библиотеку для embedded хорошо и чисто, но 99% пользователей вашей библиотеки тупо не смогут ее интегрировать. Там к сожалению в основном уровень такой дремучий, у них уже от разницы между keil и gcc шок случается, а вы им в проект еще компайлер добавить хотите?
| | |
| |
| 7.76, Аноним (76), 16:49, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> проблема раста к сожалению в том что вы конечно можете на нем
> написать библиотеку для embedded хорошо и чисто, но 99% пользователей вашей
> библиотеки тупо не смогут ее интегрировать. Там к сожалению в основном
> уровень такой дремучий, у них уже от разницы между keil и
> gcc шок случается, а вы им в проект еще компайлер добавить хотите?
А вы вообще видели чего растовики творили чтобы всего-то stack overflow на cortex M поймать этой шляпой? А то MMU там видите ли нет, а если в обычном лэйауте RAM стэк отрастет и протрет переменные - "тойота" случается. И вот эту тойоту на расте законопатить... охренеть, кастомный линкер? Спецом для? Серьезно?!
| | |
|
| 6.73, bOOster (ok), 16:14, 17/06/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Дырявого языка программирования не бывает Бывает дыра в мозгах Если у тебя в п... большой текст свёрнут, показать | | |
| |
| 7.80, ilyafedin (ok), 17:00, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если у тебя в практике программирования, как в собственной гигиене, все в порядке и четко расписано, и проверки переполнения стека ты проверяешь/моделируешь как умываешься и чистишь зубы/уши утром то проблем у тебя не будет.
Об этом уже с десяток лет говорят. Пора бы уже понять, что это не работает, CVE все также появляются и в таком же количестве. Люди допускают ошибки, на то они и люди. Единственный способ от них избавиться - убрать возможность их допускать. Что, собственно, раст и делает.
| | |
| |
| 8.109, Аноним (109), 13:39, 19/06/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Ага И как же это сделать не затрачивая ресурсы машины на проверку всего и вся, ... текст свёрнут, показать | | |
|
|
|
|
| 4.72, Gogi (??), 15:13, 17/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Как это ни смешно, но ни Го, ни Раст так и не снискали популярности, хотя за ними стоят "гиганты" ИТ. Потому что языки проектировала студота-танцоры. Они неуклюжие и откровенно, им просто нет места в интыпрайзе. Java, C#, C/C++ - эти мастодонты заняли всё. Маргинальные язычки - с ними есть очень большие риски, да и недостатки самих языков отталкивают даже "пионеров". Странно, что вообще эти го-расты ещё на слуху - такие позорные поделия должны помирать через месяц после вливания в пеар.
| | |
| |
| 5.77, Аноним (77), 16:54, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Как это ни смешно, но ни Го, ни Раст так и не
> снискали популярности, хотя за ними стоят "гиганты" ИТ.
Так разработчики fuchsia постили свои приключения в стране фуфлян^W хайпляндии. И там они походу основательно покушали счастья. Одно дело вопить как %s офигенен и совсем другое попробовать на этом драйвер железки накорябать.
| | |
| 5.96, Аноним84701 (ok), 00:29, 18/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Как это ни смешно, но ни Го, ни Раст так и не снискали популярности, хотя за ними стоят "гиганты" ИТ. Потому что языки проектировала студота-танцоры.
Обозвать Роба Пайка, Кена Томпсона и Брендан Эйха студентотой -- хороший, годный наброс :)
| | |
| 5.97, flkghdfgklh (?), 01:03, 18/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Потому что языки проектировала студота-танцоры
Создатели Go:
Кен То́мпсон (англ. Kenneth Thompson; род. 4 февраля 1943) — пионер компьютерной науки, известен своим вкладом в создание языка программирования C и операционной системы UNIX
Роб Пайк (англ. Rob Pike, род. 1956) — разработчик операционных систем и языков программирования, работавший c 1980 года в Bell Labs, где в соавторстве с другим программистом написал графический терминал Blit для Unix, и также позднее участвовал в создании операционных систем Plan 9 и Inferno. Один из создателей кодировки UTF-8
Что ты там еще про студоту будешь кукарекать, русачок?
| | |
|
| 4.104, antonimus (?), 03:44, 19/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ничто не надежно на сишке/крестах, пока код пишут человки.
> Учитывая, что до техсина еще далеко, то выход один - раст.
У каждой проблемы есть имя и фамилия.
Другого метода надежности не существует.
Пока код пишут "человеки".
Взрослей, ilyafedin, у того, кто выбирает инструмент, тоже есть имя и фамилия.
| | |
|
| 3.24, Тот_Самый_Анонимус (?), 05:19, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Есть и обратное: вера в жипеель, мол в открытом коде сразу все баги видны, не то что в этом вашем коммерческом софте.
| | |
| |
| 4.29, Аноним (-), 07:48, 17/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Открытый код в последнее время сильно активнее тестируют, однако. Можно вон какому-нибудь каверити на автомате вгрузить. А с проприетарным блобом чего делать? На слово поверить жадному корпорасу что тот старался, тестил, фиксил баги и все такое? Да щас, корпорасы жадные и довольно быстро на всю эту фигню забивают в пользу даты начала продаж.
| | |
| |
| 5.32, Тот_Самый_Анонимус (?), 07:51, 17/06/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
А что, верить производителю с открытым кодом, что он тестировал? Или верить кому-то, кто тестировал?
Вот для вас, фанатиков, именно вера нужна, без неё никуда.
| | |
| |
| 6.75, виндотролль (ok), 16:49, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 тебе же сказали, в "каверити вгрузить".
Читать глазами код даже не надо. Понятно, что не каждая уязвимость пахнет, и не каждый пахнущий код — уязвимость.
Но чутье подсказывает, что в этом Trecke код весьма сильно воняет. 19 уязвимостей! С выполнением произвольного кода.
Такое количество таких эпических CVE возможно только в открытом коде, которым никто вообще не пользуется, даже автор.
| | |
| 6.78, Аноним (77), 16:56, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> А что, верить производителю с открытым кодом, что он тестировал?
Ну, если кто например вешает себе бэджик каверити с статусом проверки - почему бы ему и не поверить что он и правда им тестировал? :)
| | |
|
|
| 4.106, antonimus (?), 03:50, 19/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Есть и обратное: вера в жипеель, мол в открытом коде сразу все
> баги видны, не то что в этом вашем коммерческом софте.
Тебе про веру напели или сам сочинил?
| | |
|
| 3.27, Аноним (-), 07:44, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> это сверхнадёжно, её же профи пишут.
Ну, вот, пишут, надеясь что никто не потыкает палочкой. "Не проктило, вычеркиваем".
| | |
| 3.37, Pahanivo (ok), 09:12, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 А кто сказал что проприетарщина не надежна?
В нее надежно запихали кучу жучков. ))
| | |
| 3.71, Gogi (??), 15:09, 17/06/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А кое-кто бредит, что проприетарщина - это сверхнадёжно, её же профи пишут
Не будь ты такой тупой, как фонатег линуnсов, ты б знал: Проприерастия не всегда пишется профи. Основной продукт пилят профи, побочные либы покупают на стороне. Вплоть до заказа в какой-нть индусячей шарашке. Шарашка пишет либу, С ВИДУ всё работает, а в реальной эксплуатации вылезают все баги и уязвимые места.
Если бы профи писали ВСЕ компоненты, софт стоил бы как чугунный мост - поэтому увы, часто мелочи отдают на откуп макакам.
| | |
| |
| 4.107, antonimus (?), 03:53, 19/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Если бы профи писали ВСЕ компоненты, софт стоил бы как чугунный мост
> - поэтому увы, часто мелочи отдают на откуп макакам.
Если бы ты был поумнее, не писал бы про чугунный мост.
| | |
|
|
| 2.10, Cradle (?), 23:24, 16/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
самое забавное что интел его похоже в своем AMT в minix встроил, это вот что такое курить нужно было?
| | |
|
| |
| 2.16, qwe (??), 01:04, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
что мешает взять lwip или uip, вот в чем вопрос. бсдя то в суровый ембеддед обычно не влазит.
| | |
| 2.44, pofigist (?), 10:48, 17/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
На мой взгляд - очевидно что. Качество кода и его монструозность заточенность под полноценный ПК, с неограниченными ресурсами (ну в разумных пределах).
А это - долбанный эмбедед, где каждый бит (не байт!!!) на счету и остальных ресурсов - с воробьиную опу...
| | |
| |
| 3.45, Cradle (?), 11:26, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
ну, про биты это уже зря, там где биты считают всетаки сабж не ставят, в основном с современными техпроцессами embedded сейчас начинается с памятей порядка нескольких килобайт, уже лет 10-15 как. Всякая старая мелочь конечно для поддержки выпускается и в количестве, но стоит снова дорого и разрабатывать под нее экономически не выгодно.
| | |
| |
| 4.57, Аноним (57), 12:15, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
И в эти несколько килобайт надо впихнуть много чего, так что байт считать таки надо.
| | |
| 4.60, pofigist (?), 12:33, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
10-15к это уже не эмбедед, а порнография какая-то :) Давно я этим делом не занимался - и тут разжирели до безобразия как я погляжу...
| | |
|
| 3.50, Аноним (47), 11:57, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>А это - долбанный эмбедед, где каждый бит (не байт!!!) на счету и остальных ресурсов - с воробьиную опу...
Чуть выше написали уже: lwIP, uIP
| | |
| |
| 4.58, pofigist (?), 12:23, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну я скорей всего думаю что стандартная проблема опенсорца - самому поддерживать очень дорого, платить разрабам - просто дорого, да и обычно они воспринимают заплаченные деньги как донат, за который они никому и ничем не обязаны. Получается что дешевле и надежней взять коммерческий проект...
| | |
| |
| 5.61, Cradle (?), 12:36, 17/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
проблема скорее в субьективных оценках, когда менеджеры (да и разработчики порой) не в состоянии сравнить все плюсы и минусы, включается мышление по типу "непонятное меня пугает, а кому я плочу с того могу требовать".
| | |
| |
| 6.67, pofigist (?), 14:05, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> проблема скорее в субьективных оценках, когда менеджеры (да и разработчики порой) не
> в состоянии сравнить все плюсы и минусы, включается мышление по типу
> "непонятное меня пугает, а кому я плочу с того могу требовать".
Да нет - просто везде вопрос денег. Риски - тоже деньги. В результате в 4х случаях из 5-ти опенсорц оказывается слишком дорогим. :)
| | |
| |
| 7.92, Аноним (92), 19:36, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Да нет - просто везде вопрос денег. Риски - тоже деньги. В
> результате в 4х случаях из 5-ти опенсорц оказывается слишком дорогим. :)
По факту проприетарщина как видим ничем таким не лучше, писана как курица лапой и всплыло через фиг знает сколько времени.
| | |
| 7.111, Аноним (111), 21:18, 21/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Наоборот, недостаточно дорогим для того, чтобы успешно прятать откаты.
| | |
|
|
|
|
|
|
| |
| |
| |
| 4.93, Аноним (92), 19:39, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Скажете в линуксах багов меньше?
В tcp/ip? Да вроде в последнее время ничего подобного в сетевом стэке не попадается.
| | |
|
|
|
| |
| 2.114, Аноним (114), 16:10, 22/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы знать чем не пользоваться (стараться избегать, не доверять важное и т.п.)
| | |
|
| 1.13, Аноним (13), 00:48, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Я уже немного стремаюсь выбирать синих, как говориться "vul#erable by default"
| | |
| 1.19, Аноним (15), 02:26, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кстати подвержены только если собраны с некоторыми опциями и компиляторами.
| | |
| |
| 2.20, anonimous (?), 03:46, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Верно. Если собирать без поддержки IPv4, IPv6, UDP, DNS, DHCP, TCP, ICMPv4 и ARP, то уязвимостей нет.
| | |
|
| 1.21, Аноним (21), 03:48, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> причиной недавних удалённых уязвимостей в подсистемах Intel AMT и ISM,
Ну вот. Это же и обсуждали пару лет назад. Вот, пожалуйста.
| | |
| |
| 2.22, Аноним (21), 03:49, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я к тому, случайно ли эти уязвимости там? И не даром гугл на своих хромбуках делает кастомную загрузку без всех этих аналов?
| | |
|
| 1.26, Аноним (26), 06:39, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> двойном освобождении памяти
Кто в курсе? Расскажите подробнее.
Ядро, нормальной, ОС при каждом освобождении памяти должно затирать освобождаемую область памяти, чтобы при её выделении другому процессу к нему не попали никакие данные.
| | |
| |
| 2.40, Ordu (ok), 09:40, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Кто в курсе? Расскажите подробнее.
В курсе чего? Тебя интересует, что такое double free? Повреждение кучи, и последующий UB.
| | |
| 2.43, Cradle (?), 10:48, 17/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
двойное освобождение бывает когда память освободили, а потом по тому же указателю еще раз. Для экономии ресурсов аллокатор не проверяет был ли этот участок уже освобожден или нет и ломает структуру кучи (heap). Выстреливает обычно в совсем другом месте программы и намного позже, и очень сложно поймать из какого места ее поломали.
| | |
| |
| 3.56, КО (?), 12:11, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Для экономии ресурсов аллокатор не проверяет был ли этот участок уже освобожден или нет и ломает структуру кучи (heap).
Ну это надо быть эпичным преждевременным оптимизатором, чтоб повторное освобождение свободного участка все порушило.
Вопрос в том, что при повторном высвобождении можно освободить уже кем-то (а может даже и тобой, но под другие цели) занятый кусок памяти, а тот кто ее занял будет не в курсе и преспокойнеько будет продолжать ей пользоваться.
| | |
| |
| 4.65, Cradle (?), 12:50, 17/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
куча это обычно связаный лист, если при повторном освобождении заголовок блока сохранился то там будет указатель на следующий блок, и слишком тупой аллокатор попытается по нему пройти дефрагментировать. Ломается именно структура кучи, и все последующие malloc/free портят ее все больше, пока где-то не выстрелит в той форме как вы описываете.
| | |
| 4.94, Ordu (ok), 22:03, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Вопрос в том, что при повторном высвобождении можно освободить уже кем-то (а может даже и тобой, но под другие цели) занятый кусок памяти, а тот кто ее занял будет не в курсе и преспокойнеько будет продолжать ей пользоваться.
Такой вариант имеет специальное название "use-after-free". Это разные баги, с точки зрения избегания и профилактики. Они похожи, могут идти совместно, но могут и порознь. Double-free случается, если хочется удалить объект, но неясно откуда это сделать. use-after-free в случаях, когда удаление проведено не полностью: free вызван, но не все указатели почищены.
| | |
| |
| 5.95, Cradle (?), 23:07, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
там видимо имелось в виду что где-то в одном потоке делаем free, потом в другом malloc и получаем указатель на тот же адрес, потом в первом потоке еще раз free, а во втором продолжаем использовать.
| | |
|
|
|
|
| 1.34, Аноним (34), 08:33, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>В проприетарном TCP/IP стеке Treck выявлено 19 уязвимостей
Это именно то, то что должен знать каждый!
Дальше не читал...
| | |
| 1.64, Anton (??), 12:42, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> администраторам рекомендуется ... запретить IPv6 multicast
Дизайнерам IPv6 нравится multicast и они приложили усилия чтобы multicast было нельзя запретить совсем: multicast используется в RA, NDP и других жизненно важных частях протокола.
| | |
| 1.69, Аноним (69), 14:40, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Из заметных целей для атак, в которых используется TCP/IP-стек Treck, можно отметить сетевые принтеры HP и чипы Intel.
И тут Intel отметился
| | |
| |
| 2.90, Аноним (90), 19:26, 17/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>И тут Intel отметился
Вы хотите сказать, что Intel специально в разных частях своей "деятельности" оставляет бэкдоры???
| | |
|
| 1.70, Gogi (??), 15:02, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> и вызваны некорректной обработкой параметров с размером данных (использование поля с размером без проверки фактического размера данных), ошибками проверки входной информации, двойном освобождении памяти, чтением из области вне буфера, целочисленными переполнениями, некорректным контролем доступа и проблемами при обработке строк с нулевым разделителем
Господи!! Этот стек что, школьники писали что ли?! Неужели столько позорных ошибок может быть в коммерческом софте? Или как всегда - "заказали в Индии"?
| | |
| |
| 2.89, Аноним (90), 19:24, 17/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Господи!! Gogi не знал, что коммерческий софт всегда некачественен!!!
| | |
|
| 1.91, Корец (?), 19:34, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>5 производителей, среди которых AMD, заявили о неподверженности своих продуктов проблемам. | | |
|
