Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
04-Май-2022 18:31

Цитировать

В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника.
Проблема затрагивает различные Linux-прошивки для маршрутизаторов, точек доступа и устройств интернета-вещей, а также Linux-дистрибутивы для встраиваемых систем, такие как OpenWRT и Embedded Gentoo. Отмечается, что уязвимость проявляется в устройствах многих производителей (например, uClibc используется в прошивках Linksys, Netgear и Axis), но так как в uClibc и uClibc-ng уязвимость остаётся неисправленной, детальные сведения о конкретных устройствах и производителях, в продуктах которых присутствует проблема, пока не разглашаются.
Уязвимость вызвана использованием в коде отправки DNS-запросов предсказуемых идентификаторов транзакции. Идентификационный номер запроса DNS выбирался путём простого увеличения счётчика без применения дополнительной рандомизации номеров портов, что позволяло добиться отравления кэша DNS через упреждающую отправку UDP-пакетов с фиктивными ответами (ответ будет принят, если он пришёл раньше ответа реального сервера и включает корректный ID). В отличие от предложенного в 2008 году метода Каминского, идентификатор транзакции даже не нужно угадывать, так как он изначально предсказуем (вначале выставляется значение 1, которое при каждом запросе увеличивается, а не выбирается случайным образом).

В спецификации для защиты от подбора идентификатора рекомендуется дополнительно применять случайное распределение номеров исходных сетевых портов, с которых отправляются DNS-запросы, что компенсирует недостаточно большой размер идентификатора. При включении рандомизации портов для формирования фиктивного ответа кроме подбора 16 битного идентификатора необходимо подобрать и номер сетевого порта. В
uClibc и uClibc-ng подобная рандомизация не включалась явно (при вызове bind не указывался случайный исходный UDP порт) и её применение зависело от настроек операционной системы.
При отключении рандомизации потов определение инкрементируемого идентификатора запроса отмечается как тривиальная задача. Но даже в случае применения рандомизации, атакующему необходимо лишь угадать сетевой порт из диапазона 32768–60999, для чего можно использовать массированную одновременную отправку фиктивных ответов по разным сетевым портам.

Наличие проблемы подтверждено во всех актуальных выпусках uClibc и uClibc-ng, включая самые свежие версии uClibc 0.9.33.2 и uClibc-ng 1.0.40. В сентябре 2021 года информация об уязвимости была отправлена в CERT/CC для согласованной подготовки исправлений. В январе 2022 года данные о проблеме были переданы более 200 производителям, сотрудничающим с CERT/CC. В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества. Из производителей о выпуске обновления с устранением уязвимости объявил NETGEAR.
===========
Источник:
OpenNet.RU
===========

Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS

Похожие новости