The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

19 удалённо эксплуатируемых уязвимостей в TCP/IP-стеке Treck

16.06.2020 22:30

В проприетарном TCP/IP стеке Treck выявлено 19 уязвимостей, эксплуатируемых через отправку специально оформленных пакетов. Уязвимостям присвоено кодовое имя Ripple20. Некоторые уязвимости также проявляются в TCP/IP-стеке KASAGO от компании Zuken Elmic (Elmic Systems), имеющем общие корни c Treck. Стек Treck применяется во многих промышленных, медицинских, коммуникационных, встраиваемых и потребительских устройствах (от умных ламп до принтеров и источников бесперебойного питания), а также в энергетическом, транспортном, авиационном, торговом и нефтедобывающем оборудовании.

Из заметных целей для атак, в которых используется TCP/IP-стек Treck, можно отметить сетевые принтеры HP и чипы Intel. В том числе проблемы в TCP/IP-стеке Treck оказались причиной недавних удалённых уязвимостей в подсистемах Intel AMT и ISM, эксплуатируемых через отправку сетевого пакета. Наличие уязвимостей подтвердили производители Intel, HP, Hewlett Packard Enterprise, Baxter, Caterpillar, Digi, Rockwell Automation и Schneider Electric. Ещё 66 производителей, в продуктах которых используется TCP/IP-стек Treck, пока не отреагировали на проблемы. 5 производителей, среди которых AMD, заявили о неподверженности своих продуктов проблемам.

Проблемы найдены в реализации протоколов IPv4, IPv6, UDP, DNS, DHCP, TCP, ICMPv4 и ARP, и вызваны некорректной обработкой параметров с размером данных (использование поля с размером без проверки фактического размера данных), ошибками проверки входной информации, двойном освобождении памяти, чтением из области вне буфера, целочисленными переполнениями, некорректным контролем доступа и проблемами при обработке строк с нулевым разделителем.

Две наиболее опасные проблемы (CVE-2020-11896, CVE-2020-11897) , которым присвоен уровень CVSS 10, позволяют выполнить свой код на устройстве через отправку определённым образом оформленных пакетов IPv4/UDP или IPv6. Первая критическая проблема проявляется на устройствах с поддержкой IPv4-туннелей, а вторая в выпущенных до 04.06.2009 версиях с поддержкой IPv6. Ещё одна критическая уязвимость (CVSS 9) присутствует в DNS-резолвере (CVE-2020-11901) и позволяет выполнить код через отправку специально оформленного DNS-запроса (проблема использована для демонстрации взлома Schneider Electric APC UPS и проявляется на устройствах с поддержкой DNS).

Другие уязвимости CVE-2020-11898, CVE-2020-11899, CVE-2020-11902, CVE-2020-11903, CVE-2020-11905 позволяют через отправку специально оформленных пакетов IPv4/ICMPv4, IPv6OverIPv4, DHCP, DHCPv6 или IPv6 узнать содержимое областей памяти системы. Остальные проблемы могут привести к отказу в обслуживании или утечке остаточных данных из системных буферов.

Большинство уязвимостей устранены в выпуске Treck 6.0.1.67 (проблема CVE-2020-11897 устранена в 5.0.1.35, CVE-2020-11900 в 6.0.1.41, CVE-2020-11903 в 6.0.1.28, CVE-2020-11908 в 4.7.1.27). Так как подготовка обновлений прошивок для конкретных устройств может затянуться или невозможна (стек Treck поставляется более 20 лет, многие устройства остались без сопровождения или их проблематично обновить), администраторам рекомендуется изолировать проблемные устройства и настроить на системах инспектирования пакетов, межсетевых экранах или маршрутизаторах нормализацию или блокирование фрагментированных пакетов, заблокировать IP-туннели (IPv6-in-IPv4 и IP-in-IP), заблокировать "source routing", активировать инспектирование некорректных опций в TCP-пакетах, блокировать неиспользуемые управляющие ICMP-сообщения (MTU Update и Address Mask), запретить IPv6 multicast и перенаправлять DNS-запросы к защищённому рекурсивному DNS-серверу.



  1. Главная ссылка к новости (https://kb.cert.org/vuls/id/25...)
  2. OpenNews: 11 удалённо эксплуатируемых уязвимостей в TCP/IP стеке VxWorks
  3. OpenNews: В TCP/IP-стеке FreeRTOS выявлены уязвимости, приводящие к удалённому выполнению кода
  4. OpenNews: Уязвимости в TCP-стеках Linux и FreeBSD, приводящие к удалённому отказу в обслуживании
  5. OpenNews: Уязвимость в сетевом стеке ядра Linux
  6. OpenNews: BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стеках Linux, Android, iOS и Windows
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53170-treck
Ключевые слова: treck, tcpip, iot
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (109) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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.25, Аноним (25), 06:02, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На котором не напишешь ни один TCP/IP-стек без unsafe?
     
  • 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.82, Michael Shigorin (ok), 17:36, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Раст убивает людей ... текст свёрнут, показать
     
     
  • 9.99, bOOster (ok), 05:57, 18/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    CELL BROADBAND ENGINE программировать можешь ... текст свёрнут, показать
     
  • 9.102, bOOster (ok), 22:19, 18/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    программистов которвх Сортировка и Поиск Кнута ... текст свёрнут, показать
     
  • 8.98, bOOster (ok), 05:53, 18/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так мы РАСТ по выходным и инспектируем ... текст свёрнут, показать
     
  • 8.105, antonimus (?), 03:48, 19/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну невозможно быть настолько тупым Или таки возможно Ни в каком языке программ... текст свёрнут, показать
     
     
  • 9.108, ilyafedin (ok), 04:08, 19/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Логической - нет А вот всякие переполнения буферов и прочие из-за небезопасности... текст свёрнут, показать
     
  • 8.109, Аноним (109), 13:39, 19/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ага И как же это сделать не затрачивая ресурсы машины на проверку всего и вся, ... текст свёрнут, показать
     
     
  • 9.110, ilyafedin (ok), 19:04, 19/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Странная аналогия, у раста все проверки в compile-time... текст свёрнут, показать
     
  • 4.42, Онаним (?), 10:37, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Запихаете TCP-стек на п**расте в эмбедовку - приходите.
     
  • 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.41, Аноним (41), 10:34, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, когда аргументов нет, тогда и начинаются вера-фанатики.
     
  • 6.46, Cradle (?), 11:39, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    "не нужно звать, не нужно ждать, а можно взять и почитать"
     
  • 6.47, Аноним (47), 11:48, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не веришь - протестируй сам, найми аудитора. Код в наличии.
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    А кто сказал что проприетарщина не надежна?
    В нее надежно запихали кучу жучков. ))
     
     
  • 4.48, Аноним (47), 11:51, 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 встроил, это вот что такое курить нужно было?
     
     
  • 3.30, Аноним (-), 07:50, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для начала что надо было курить чтобы вообще ME встроить.
     
     
  • 4.49, Аноним (47), 11:53, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Просто из уважения к ББ.
     
  • 4.83, Michael Shigorin (ok), 17:39, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Насяльника велел!
     
  • 2.66, little Bobby tables (?), 12:51, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    сделай на дипидикей потом  дергайся
     
  • 2.85, Аноним (85), 18:42, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Завидуйте молча.
     

  • 1.2, commiethebeastie (ok), 23:03, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Даёшь ботнет на миллионы устройств.
     
     
  • 2.55, Аноним (47), 12:10, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Other BoT devices
     

  • 1.3, Аноним (3), 23:08, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Вполне ожидаемо от проприетарного продукта.
     
  • 1.4, анонимно (?), 23:08, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    что мешает взять код из FreeBSD? Не понятно.
     
     
  • 2.7, Аноним (7), 23:19, 16/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Из NetBSD,как сделали в QNX.
     
     
  • 3.17, antonimus (?), 01:05, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Из NetBSD,как сделали в QNX.

    QNX - сейчас Blackberry, а ты не в курсе?

     
     
  • 4.59, Совершенно другой аноним (?), 12:26, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так и фирма была QSSL, а не QNX. Как я понимаю, под QNX имелась в виду ОС.
     
  • 4.79, Аноним (77), 16:57, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > сейчас Blackberry,

    А оно вообще еще живое?


     
     
  • 5.103, antonimus (?), 03:38, 19/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> сейчас Blackberry,
    > А оно вообще еще живое?

    А тебя фиксики забанили?

     
  • 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к это уже не эмбедед, а порнография какая-то :) Давно я этим делом не занимался - и тут разжирели до безобразия как я погляжу...
     
     
  • 5.63, Cradle (?), 12:38, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да, меньше 8kb сейчас уже не делает чип дешевле
     
  • 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-ти опенсорц оказывается слишком дорогим. :)

    По факту проприетарщина как видим ничем таким не лучше, писана как курица лапой и всплыло через фиг знает сколько времени.


     
     
  • 8.100, pofigist (?), 12:20, 18/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Эти риски покрыла страховка А вот сумасшедших, чтоб застраховать риски связанны... текст свёрнут, показать
     
  • 7.111, Аноним (111), 21:18, 21/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот, недостаточно дорогим для того, чтобы успешно прятать откаты.
     
     
  • 8.112, pofigist (?), 16:04, 22/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ха Вот уж где откаты рулят, так это при внедрении опенсорца Там все расходы ... текст свёрнут, показать
     

  • 1.5, Сейд (ok), 23:10, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это ужасно.
     
     
  • 2.9, Аноним (8), 23:22, 16/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это корпорации. И такое везде в проприетарных продуктах.
     
     
  • 3.86, Аноним (85), 18:44, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Скажете в линуксах багов меньше?
     
     
  • 4.88, Сейд (ok), 19:06, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В lwIP меньше.
     
  • 4.93, Аноним (92), 19:39, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Скажете в линуксах багов меньше?

    В tcp/ip? Да вроде в последнее время ничего подобного в сетевом стэке не попадается.

     

  • 1.6, Аноним (6), 23:18, 16/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >В проприетарном

    Зачем проприетарастопроблемы на опеннете?

     
     
  • 2.11, Аноним (11), 23:41, 16/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пропаганда всего свободного и открытого!
     
  • 2.114, Аноним (114), 16:10, 22/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы знать чем не пользоваться (стараться избегать, не доверять важное и т.п.)
     

  • 1.13, Аноним (13), 00:48, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я уже немного стремаюсь выбирать синих, как говориться "vul#erable by default"
     
     
  • 2.33, Аноним (33), 08:25, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    By design скорее.
     
  • 2.52, YetAnotherOnanym (ok), 12:01, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кагбэ, синими принято называть МежДелМаш, ващще-то.
     
     
  • 3.54, Аноним (47), 12:05, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    МежДелМаш сине-бело-полосатые
     
  • 3.84, Michael Shigorin (ok), 17:40, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То крепко синие (big blue)...
     

  • 1.15, Аноним (15), 00:54, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    За фиг знает знает сколько лет нашли уязвимость в древней версии
     
  • 1.18, YetAnotherOnanym (ok), 01:18, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хы... Там, где "Power grid" должна быть, по идее, опора ЛЭП, а вместо этого там стоит значок антенной мачты.
     
  • 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 уязвимостей

    Это именно то, то что должен знать каждый!

    Дальше не читал...

     
     
  • 2.62, Аноним (62), 12:37, 17/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, поржал
     

  • 1.64, Anton (??), 12:42, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > администраторам рекомендуется ... запретить IPv6 multicast

    Дизайнерам IPv6 нравится multicast и они приложили усилия чтобы multicast было нельзя запретить совсем: multicast используется в RA, NDP и других жизненно важных частях протокола.

     
  • 1.68, Ананоним (?), 14:22, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Даёшь больше дырок весёлых и нужных!"
     
  • 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.87, Повидло19 (?), 18:48, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что вы хотите от вещи с названием "Треск"?
     
  • 1.91, Корец (?), 19:34, 17/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >5 производителей, среди которых AMD, заявили о неподверженности своих продуктов проблемам.
     
  • 1.101, Аноним (101), 19:21, 18/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прочитал как - 19 лет эксплуатируемые
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру