Sicherheitsanfälligkeit in uClibc und uClibc-ng, die es ermöglicht, Daten im DNS-Cache zu manipulieren

In den Standard-C-Bibliotheken uClibc und uClibc-ng, die in vielen eingebetteten und tragbaren Geräten verwendet werden, wurde eine Sicherheitsanfälligkeit festgestellt (CVE noch nicht zugewiesen), die es ermöglicht, gefälschte Daten in den DNS-Cache einzufügen, was genutzt werden kann, um die IP-Adresse einer beliebigen Domain im Cache zu ändern und Anfragen an die Domain auf den Server eines Angreifers umzuleiten.

Das Problem betrifft verschiedene Linux-Firmware für Router, Zugangspunkte und IoT-Geräte sowie Linux-Distributionen für eingebettete Systeme wie OpenWRT und Embedded Gentoo. Es wird festgestellt, dass die Sicherheitsanfälligkeit in Geräten vieler Hersteller auftritt (zum Beispiel wird uClibc in den Firmware-Versionen von Linksys, Netgear und Axis verwendet), aber da die Schwachstelle in uClibc und uClibc-ng ungepatcht bleibt, sind detaillierte Informationen über spezifische Geräte und Hersteller, die von dem Problem betroffen sind, noch nicht bekanntgegeben worden.

Die Sicherheitsanfälligkeit wird durch die Verwendung vorhersehbarer Transaktionsidentifikatoren im Code zum Senden von DNS-Anfragen verursacht. Die Identifikationsnummer der DNS-Anfrage wurde einfach durch Erhöhen eines Zählers gewählt, ohne zusätzliche Randomisierung der Portnummern anzuwenden, was es ermöglichte, den DNS-Cache durch vorsorgliches Senden von UDP-Paketen mit gefälschten Antworten zu vergiften (die Antwort wird akzeptiert, wenn sie vor der Antwort des echten Servers eintrifft und die korrekte ID enthält). Server Im Gegensatz zur Methode von Kaminsky, die 2008 vorgeschlagen wurde, muss der Transaktionsidentifikator nicht geraten werden, da er von Anfang an vorhersehbar ist (anfangs wird der Wert 1 festgelegt, der bei jeder Anfrage erhöht wird und nicht zufällig ausgewählt wird).

In der Spezifikation zum Schutz vor dem Raten der ID wird empfohlen, zusätzlich eine zufällige Verteilung der Quellnetzwerkportnummern anzuwenden, von denen die DNS-Anfragen gesendet werden, um den nicht ausreichend großen Identifikator auszugleichen. Bei Aktivierung der Port-Randomisierung zur Bildung einer gefälschten Antwort muss neben dem Raten des 16-Bit-Identifikators auch die Netzwerkportnummer erraten werden. In uClibc und uClibc-ng wurde eine solche Randomisierung nicht ausdrücklich aktiviert (bei der Bind()-Aufruf wurde kein zufälliger Ausgangs-UDP-Port angegeben) und ihre Anwendung hing von den Einstellungen des Betriebssystems ab.

Bei der Deaktivierung der Zufälligkeit wird die Bestimmung der inkrementellen Anforderungs-ID als triviale Aufgabe betrachtet. Selbst bei Anwendung der Zufälligkeit muss der Angreifer nur den Netzwerkport aus dem Bereich von 32768 bis 60999 erraten, wofür er eine massenhafte gleichzeitige Sendung gefälschter Antworten über verschiedene Netzwerkports nutzen kann.

Das Problem wurde in allen aktuellen Versionen von uClibc und uClibc-ng bestätigt, einschließlich der neuesten Versionen uClibc 0.9.33.2 und uClibc-ng 1.0.40. Im September 2021 wurde die Information über die Schwachstelle an CERT/CC gesendet, um eine koordinierte Vorbereitung von Korrekturen zu ermöglichen. Im Januar 2022 wurden die Informationen über das Problem an über 200 Hersteller weitergegeben, die mit CERT/CC zusammenarbeiten. Im März wurde versucht, separat Kontakt mit dem Wartungsteam des uClibc-ng-Projekts aufzunehmen, jedoch antworteten sie, dass sie nicht in der Lage sind, die Schwachstelle eigenständig zu beheben, und empfahlen, die Informationen über das Problem öffentlich preiszugeben, in der Hoffnung, Unterstützung von der Community bei der Entwicklung eines Patches zu erhalten. Von den Herstellern kündigte NETGEAR eine Aktualisierung zur Behebung der Schwachstelle an.

Quelle: opennet.ru