Преди няколко дни излезе новината, че в стандартните библиотеки на C uClibc и uClibc-ng, използван в много вградени и преносими устройства, е установена уязвимост (с CVE все още не е присвоен), което позволява заместване на фиктивни данни в DNS кеша, който може да се използва за подправяне на IP адреса на произволен домейн в кеша и пренасочване на заявки към домейна към сървъра на нападателя.
За проблема се споменава, че това засяга различни фърмуери на Linux за рутери, точки за достъп и IoT устройства, както и вградени Linux дистрибуции като OpenWRT и Embedded Gentoo.
Относно уязвимостта
Уязвимост се дължи на използването на предвидими идентификатори на транзакции в кода за изпращане на заявки на DNS. Идентификаторът на DNS заявката беше избран чрез просто увеличаване на брояча без допълнително рандомизиране на номерата на портовете, което направи възможно отравянето на DNS кеша чрез превантивно изпращане на UDP пакети с фалшиви отговори (отговорът ще бъде приет, ако пристигне преди отговора от реалния сървър и включва правилната идентификация).
За разлика от метода на Камински, предложен през 2008 г., дори не е необходимо да се отгатва идентификационният номер на транзакцията, тъй като първоначално е предвидим (първоначално е зададен на 1, което се увеличава с всяка заявка и не се избира на случаен принцип).
за да се предпазите срещу отгатване на ID, спецификацията освен това препоръчва използването на произволно разпределение на номерата на мрежовите портове на произход, от който се изпращат DNS заявките, което компенсира недостатъчния размер на ID.
Когато рандомизацията на портовете е разрешена, за да се формира фиктивен отговор, в допълнение към избора на 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, подробна информация за устройствата и конкретни производители, в чиито продукти има проблем, докато не бъдат разкрити.
Накрая ако се интересувате да научите повече за това, можете да проверите подробностите В следващия линк.