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

В стандартных Си-библиотеках 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, которое при каждом запросе увеличивается, а не выбирается случайным образом).

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

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

При отключении рандомизации потов определение инкрементируемого идентификатора запроса отмечается как тривиальная задача. Но даже в случае применения рандомизации, атакующему необходимо лишь угадать сетевой порт из диапазона 32768–60999, для чего можно использовать массированную одновременную отправку фиктивных ответов по разным сетевым портам.

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

Наличие проблемы подтверждено во всех актуальных выпусках 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

Добавить комментарий