CVE-2026-79980

Beschreibung

Der DHCPv4-Client in subsys/net/lib/dhcpv4/dhcpv4.c behielt seine Transaktionskennung (iface->config.dhcpv4.xid) als Zähler und nicht als Zufallswert pro Transaktion bei. Es wurde einmal mit sys rand32 get() in dhcpv4 start internal() ausgesät, um eins in dhcpv4 send discover() und dhcpv4 send decline() erhöht und nie durch dhcpv4 send request() geändert - so dass jeder RENEWING- und REBINDING-Austausch unverändert die Kennung wiederverwendet hat, die bereits auf der Leitung im Broadcast-DHCPDISCOVER beim Booten erschienen war, und wo die Kennung sie vorhersagbar um eins verschoben hat. RFC 2131 4.1 erfordert eine einzige Kennung pro Transaktion, die so ausgewählt ist, dass es unwahrscheinlich ist, dass Kunden kollidieren. Diese Kennung ist das einzige unvorhersehbare Antwortvalidierungstoken des Clients. net dhcpv4 input() akzeptiert eine BOOTP-Antwort auf op, eine passende xid und eine passende chaddr (die Schnittstelle MAC, die öffentlich ist); der UDP-Callback wird mit einer Platzhalter-Remoteadresse und einem Port registriert, und es wird keine Server-Identifikator- oder Quelladressenüberprüfung durchgeführt. Ein Angreifer, der einen Bezeichner lernt - zum Beispiel einen Host im selben Segment, der den ausgestrahlten DHCPDISCOVER oder einen DHCP-Server oder ein Relais in einem Netzwerk sieht, dem das Gerät zuvor beigetreten ist - behält daher ein gültiges Token für die gesamte Betriebszeit des Geräts und kann die Bezeichner späterer Austausche vorhersagen, ohne den unicast erneuernden Datenverkehr beobachten zu müssen oder den legitimen Server zu fahren. Eine gefälschte Antwort, die diese Prüfungen besteht, hat unabhängig vom Clientzustand Wirkung, da dhcpv4 parse options() seine Nebeneffekte vor dem State Machine Gate in dhcpv4 handle reply() anwendet: die Router-Option ruft net if ipv4 set gw() und die DNS-Option ruft dns resolve reconfigure() auf. Ein einzelnes akzeptiertes Datagramm kann somit das Standard-Gateway und die Resolver des Geräts an angreifergesteuerte Adressen verweisen und seinen Datenverkehr umleiten; während RENEWING oder REBINDING bindet ein gefälschtes DHCPACK den Leasingvertrag mit vom Angreifer ausgewählten Parametern neu und ein gefälschtes DHCPNAK entfernt die Adresse und startet die Konfiguration neu. Der Fix zieht einen neuen sys rand32 get()-Wert an jedem Punkt, an dem eine Transaktion beginnt – Eingabe SELECTING, RENEWING und REBINDING, und an dem INIT/INIT-REBOOT-Eintrag, wenn eine Schnittstelle mit einem Leasing ausfällt – während REQUESTING und DECLINE die Kennung des Austauschs behalten, zu dem sie gehören, wie RFC 2131 es verlangt. Als Nebeneffekt verwirft der Client auch nicht mehr das Angebot eines langsamen Servers nach der erneuten Übertragung eines Discovers, und der Initial-Discover-Backoff zieht nun seine eigene Zufälligkeit, anstatt sie aus dem Identifikator abzuleiten.

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.