Несколько дней назад появилась новость о том, что в стандартных библиотеках C uClibc и uClibc-ng, используемый во многих встроенных и портативных устройствах, была обнаружена уязвимость (с еще не назначенным CVE), что позволяет подменять фиктивные данные в кеше DNS, что может быть использовано для подмены IP-адреса произвольного домена в кеше и перенаправления запросов к домену на сервер злоумышленника.
О проблеме упоминается, что это влияет на различные прошивки Linux для маршрутизаторов, точек доступа и IoT-устройств, а также встроенные дистрибутивы Linux, такие как OpenWRT и Embedded Gentoo.
Об уязвимости
Уязвимость связано с использованием предсказуемых идентификаторов транзакций в коде для отправки запросов DNS. Идентификатор DNS-запроса был выбран путем простого увеличения счетчика без дальнейшей рандомизации номеров портов, что дал возможность отравить кеш DNS за счет упреждающей отправки UDP-пакетов с поддельными ответами (ответ будет принят, если он прибудет раньше ответа от реального сервера и будет содержать правильную идентификацию).
В отличие от метода Каминского, предложенного в 2008 году, ID транзакции даже не нужно угадывать, так как он изначально предсказуем (изначально установлен в 1, который увеличивается с каждым запросом, а не выбирается случайным образом).
Чтобы защитить себя против угадывания идентификатора, спецификация далее рекомендует использовать случайное распределение номеров сетевых портов источника, из которого отправляются DNS-запросы, что компенсирует недостаточный размер идентификатора.
При включенной рандомизации портов для формирования фиктивного ответа помимо выбора 16-битного идентификатора необходимо также выбрать номер сетевого порта. В uClibc и uClibc-ng такая рандомизация явно не включалась (при вызове bind не указывался случайный UDP-порт источника) и ее реализация зависела от конфигурации операционной системы.
Когда рандомизация портов отключена, определение идентификатора запроса для увеличения помечено как тривиальная задача. Но даже в случае рандомизации злоумышленнику достаточно угадать сетевой порт из диапазона 32768-60999, для чего он может использовать массовую одновременную отправку фиктивных ответов на разные сетевые порты.
Проблема подтверждено во всех текущих версиях uClibc и uClibc-ng, включая последние версии uClibc 0.9.33.2 и uClibc-ng 1.0.40.
«Важно отметить, что уязвимость, затрагивающая стандартную библиотеку C, может быть довольно сложной», — написала команда в своем блоге на этой неделе.
«Мало того, что будут сотни или тысячи вызовов уязвимой функции в нескольких точках одной программы, уязвимость затронет неопределенное количество других программ от разных поставщиков, настроенных на использование этой библиотеки».
В сентябре 2021 года была отправлена информация об уязвимости в CERT/CC для координированной подготовки массива. В январе 2022 г. проблему поделили с более чем 200 производителями связанный с CERT/CC.
В марте была попытка отдельно связаться с мейнтейнером проекта uClibc-ng, но тот ответил, что не может самостоятельно устранить уязвимость и рекомендовал публично раскрыть информацию о проблеме, надеясь получить помощь в разработке исправления. общество. От производителей NETGEAR объявила о выпуске обновления с устранением уязвимости.
Важно отметить, что уязвимость, затрагивающая стандартную библиотеку C, может быть довольно сложной. Мало того, что будут сотни или тысячи вызовов уязвимой функции в нескольких точках одной программы, уязвимость затронет неопределенное количество других программ от разных поставщиков, сконфигурированных для использования этой библиотеки.
Отмечается, что уязвимость проявляется в устройствах многих производителей (например, uClibc используется в прошивках от Linksys, Netgear и Axis), но поскольку в uClibc и uClibc-ng уязвимость остается неисправленной, подробная информация об устройствах и конкретных производителей, в продукции которых есть проблемы, пока они не будут раскрыты.
В конце концов если вам интересно узнать об этом больше, вы можете проверить подробности По следующей ссылке.