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