Уязвимости во FreeBSD, IPnet и Nucleus NET, связанные с ошибками при реализации сжатия в DNS
13 апреля 2021 года
Исследовательские группы Forescout Research Labs и JSOF Research опубликовали результаты совместного исследования безопасности различных реализаций схемы сжатия, применяемой для упаковки повторяющихся имён в сообщениях DNS, mDNS, DHCP и IPv6 RA (упаковка дублирующихся частей доменов в сообщениях, включающих несколько имён). В ходе проведённой работы было выявлено 9 уязвимостей, которые обобщены под кодовым именем NAME:WRECK.
Проблемы выявлены во FreeBSD, а также в сетевых подсистемах IPnet, Nucleus NET и NetX, получивших распространение в операционных системах реального времени VxWorks, Nucleus и ThreadX, применяемых в устройствах автоматизации, хранилищах, медицинских приборах, авионике, принтерах и потребительской электронике. Предполагается, что уязвимостям подвержено как минимум 100 миллионов устройств.
- Уязвимость во FreeBSD (CVE-2020-7461) позволяла организовать выполнение своего кода через отправку атакующим, находящемся в одной локальной сети с жертвой, специально оформленного DHCP-пакета, обработка которого уязвимым DHCP-клиентом приводила к переполнению буфера. Проблему смягчало то, что процесс dhclient, в котором присутствует уязвимость, выполнялся со сброшенными привилегиями в изолированном окружении Capsicum, для выхода из которого требовалось выявление ещё одной уязвимости.
Суть ошибки в некорректной проверке параметров, в возвращаемом DHCP-сервером пакете c 119-опцией DHCP, позволяющей передать список "domain search" для резолвера. Неверный расчёт размера буфера, необходимого для размещения распакованных доменных имён, приводил к записи контролируемой атакующим информации за пределы выделенного буфера. Во FreeBSD проблема устранена ещё в сентябре прошлого года. Проблема может быть эксплуатирована только при наличии доступа к локальной сети.
- Уязвимость во встраиваемом сетевом стеке IPnet, применяемом в RTOS VxWorks, позволяет потенциально выполнить код на стороне DNS-клиента из-за неверной обработки сжатия DNS-сообщений. Как оказалось, впервые данная уязвимость была выявлена компаний Exodus ещё в 2016 году, но так и не была исправлена. Новый запрос в компанию Wind River также остался без ответа и устройства с IPnet остаются уязвимы.
- В TCP/IP стеке Nucleus NET, поддерживаемом компанией Siemens, выявлено 6 уязвимостей, из которых две могли привести к удалённому выполнению кода, а четыре к инициированию отказа в обслуживании. Первая опасная проблема связана с ошибкой при распаковке сжатых сообщений DNS, а вторая c некорректным разбором меток доменных имён. Обе проблемы приводят к переполнению буфера при обработки специально оформленных ответов DNS.
Для эксплуатации уязвимостей атакующему достаточно отправить специально оформленный ответ на любой легитимный запрос, отправленный с уязвимого устройства, например, через проведение MTIM-атаки и вклинивание в трафик между DNS-сервером и жертвой. Если атакующий имеет доступ к локальной сети, то он может запустить DNS-сервер, пытающийся атаковать проблемные устройства через рассылку запросов mDNS в широковещательном режиме.
- Уязвимость в сетевом стеке NetX (Azure RTOS NetX), разработанном для ThreadX RTOS и открытого в 2019 году после перехода в руки Microsoft, ограничилась отказом в обслуживании. Проблема вызвана ошибкой разбора сжатых сообщений DNS в реализации резолвера.
Из проверенных сетевых стеков, в которых не быдло найдено уязвимостей, связанных со сжатием повторяющихся данных в DNS-сообщениях, названы проекты lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP, OpenThread и FNET. При этом первые два (Nut/Net и lwIP) вообще не поддерживают сжатие в DNS-сообщениях, а остальные реализуют данную операцию без ошибок. Кроме того, отмечается, что ранее те же исследователи уже выявляли похожие уязвимости в стеках Treck, uIP и PicoTCP.
Источники[править]
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.