CVE-2026-79981

Beschreibung

Der DNS-Stub-Resolver in subsys/net/lib/dns/resolve.c bindet einen UDP-Socket pro konfiguriertem Server, wenn der Resolver-Kontext initialisiert wird (dns resolve init locked() -> register dispatcher() -> dns dispatcher register()), wobei der lokale Port bei 0 bleibt, so dass der Stack genau einmal einen ephemeren Port auswählt. dns write() sendet dann jede nachfolgende Abfrage aus demselben Socket ohne erneute Bindung, so dass der Source-Port für die Lebensdauer des Resolver-Kontexts konstant ist, während nur die 16-Bit-Transaktionskennung (ctx->queries[i].id, gezeichnet mit sys rand16 get()) pro Abfrage variiert. RFC 5452 Abschnitt 9.2 erfordert, dass beide variieren; mit einem festen Port muss ein Off-Path-Angreifer nur die Kennung erraten. Der stabile Hafen ist billig zu lernen. Jede einzelne beobachtete Abfrage zeigt sie dauerhaft, und sie kann auch durch Sondieren des ephemeren UDP-Bereichs gefunden werden: subsys/net/ip/connection.c beantwortet unübertroffenes unicast UDP mit einem ICMP-Port-unerreichbar, so dass der Sockel des Resolvers der eine Port in diesem Bereich ist, der still bleibt. Die Annahme einer Antwort wird ausschließlich durch get slot by id() entschieden, die mit der Transaktionskennung und einem CRC-16 des abgefragten Namens übereinstimmt - die Quelladresse der Antwort wird nie überprüft (dispatcher cb() tut ARG UNUSED(addr)), so dass gefälschte Antworten nicht einmal gefälscht werden müssen, um vom konfigurierten Server zu kommen; Sie müssen nur den Port des Resolvers erreichen. Ein Angreifer mit UDP-Erreichbarkeit auf das Gerät (gleiches LAN-, Wi-Fi- oder Mesh-Segment oder eine global routbare Geräteadresse) kann daher während eines Abfragefensters Antworten auf einen vorhersagbaren Abfragenamen über den 16-Bit-Kennungsbereich hinweg überfluten und den legitimen Server befahren. Ein Gewinn lässt die Anwendung eine vom Angreifer ausgewählte Adresse auflösen, und wenn CONFIG DNS RESOLVER CACHE aktiviert ist, wird der gefälschte Datensatz für seine vom Angreifer ausgewählte TTL beibehalten. Der Angriff erfordert immer noch das Gewinnen dieses Rennens, und Anwendungen, die TLS-Zertifikate für den aufgelösten Endpunkt validieren, sind weitgehend geschützt. Der Fix zieht vor jeder Abfrage einen neuen lokalen Port an einen Server, der nichts Herausstehendes hat: dns randomize source port() unregistriert den Dispatcher, schließt und öffnet den Socket und registriert ihn erneut an Port 0, so dass das System einen neuen Port auswählt, wodurch der pro Abfrage ermittelte Speicherplatz von etwa 16 auf etwa 31 Bit erhöht wird. Multicast DNS und LLMNR sind ausgeschlossen, da ihre Ports protokollfest sind. Das Verhalten wird gesteuert durch CONFIG DNS RESOLVER RANDOMIZE SOURCE PORT (Standard y).

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.