CVE-2026-79980 in Zephyr
Zusammenfassung
von VulDB • 23.10.2026
Der DHCPv4-Client in subsys/net/lib/dhcpv4/dhcpv4.c verwaltete seine Transaktionskennung (iface->config.dhcpv4.xid) als Zähler, anstatt sie als einen pro Transaktion zufälligen Wert zu führen. Sie wurde einmal mit sys_rand32_get() in dhcpv4_start_internal() initialisiert, um eins erhöht in dhcpv4_send_discover() und dhcpv4_send_decline(), und niemals geändert durch dhcpv4_send_request(). Daher wurden bei jeder RENEWING- und REBINDING-Austausch die Kennung unverändert wiederverwendet, wie sie bereits im broadcast DHCPDISCOVER beim Booten auf der Leitung erschienen war; wo sich die Kennung änderte, geschah dies vorhersehbar um eins. RFC 2131 Abschnitt 4.1 verlangt eine einzelne Kennung pro Transaktion, so gewählt, dass Kollisionen zwischen Clients unwahrscheinlich sind.
Diese Kennung ist das einzige unvorhersehbare Token zur Validierung von Antworten des Clients. net_dhcpv4_input() akzeptiert eine BOOTP-Antwort basierend auf op (Operation), einer übereinstimmenden xid und einer übereinstimmenden chaddr (die MAC-Adresse der Schnittstelle, die öffentlich ist); der UDP-Callback wird mit einer Wildcard für Remote-Adresse und Port registriert, und es werden keine Prüfungen von server-identifier oder source-address angewendet. Ein Angreifer, der eine Kennung erlernt hat – beispielsweise jeder Host im gleichen Segment, der den broadcast DHCPDISCOVER sieht, oder ein DHCP-Server oder Relay in einem Netzwerk, dem das Gerät zuvor beigetreten ist –, behält daher für die gesamte Laufzeit des Geräts ein gültiges Token und kann die Kennungen späterer Austausche vorhersagen, ohne den unicast Renew-Traffic beobachten zu müssen oder mit dem legitimen Server um Zeitvorteile (Race Condition) konkurrieren zu müssen.
Eine gefälschte Antwort, die diese Prüfungen besteht, hat unabhängig vom Client-Status Wirkung, da dhcpv4_parse_options() seine Nebenwirkungen vor der Zustandsmaschinen-Sperre in dhcpv4_handle_reply() anwendet: Die Router-Option ruft net_if_ipv4_set_gw() auf und die DNS-Option ruft dns_resolve_reconfigure() auf. Ein einzelnes akzeptiertes Datagramm kann somit das Standard-Gateway des Geräts sowie seine Resolver auf vom Angreifer kontrollierte Adressen umleiten und seinen Traffic umlenken; während RENEWING oder REBINDING bindet eine gefälschte DHCPACK die Lease mit vom Angreifer gewählten Parametern neu, und ein gefälschtes DHCPNAK entfernt die Adresse und startet die Konfiguration erneut.
Die Korrektur zieht bei jedem Punkt, an dem eine Transaktion beginnt – beim Eintritt in SELECTING, RENEWING und REBINDING sowie am INIT/INIT-REBOOT-Eintritt, wenn eine Schnittstelle mit einer Lease ausfällt – einen frischen sys_rand32_get()-Wert; während REQUESTING und DECLINE die Kennung der Austauschphase beibehalten, zu der sie gehören, wie es RFC 2131 erfordert. Als Nebeneffekt verwirft der Client zudem kein Angebot eines langsamen Servers mehr nach dem erneuten Senden einer Discover-Nachricht, und das Backoff-Verhalten für den initialen Discover-Zugriff bezieht nun seine eigene Zufälligkeit anstelle dieser aus der Kennung abzuleiten.
VulDB is the best source for vulnerability data and more expert information about this specific topic.