GHSA-p2q6-38x2-wmc8: Predictable and reused DHCPv4 transaction identifier allows spoofed DHCP replies to reconfigure gateway and DNS
The DHCPv4 client in subsys/net/lib/dhcpv4/dhcpv4.c maintained its transaction identifier (iface->config.dhcpv4.xid) as a counter rather than as a per-transaction random value. It was seeded once with sysrand32get() in dhcpv4startinternal(), incremented by one in dhcpv4senddiscover() and dhcpv4senddecline(), and never changed by dhcpv4sendrequest() — so every RENEWING and REBINDING exchange reused, unchanged, the identifier that had already appeared on the wire in the broadcast DHCPDISCOVER at boot, and where the identifier did move it moved predictably by one. RFC 2131 4.1 requires a single identifier per transaction, chosen so that clients are unlikely to collide.
This identifier is the client's only unpredictable reply-validation token. netdhcpv4input() accepts a BOOTP reply on op, a matching xid, and a matching chaddr (the interface MAC, which is public); the UDP callback is registered with a wildcard remote address and port, and no server-identifier or source-address check is applied. An attacker who learns one identifier — for example any host on the same segment that sees the broadcast DHCPDISCOVER, or a DHCP server or relay on a network the device previously joined — therefore retains a valid token for the device's whole uptime, and can predict the identifiers of later exchanges, without having to observe the unicast renew traffic or race the legitimate server.
A forged reply that passes those checks has effect regardless of client state, because dhcpv4parseoptions() applies its side effects before the state machine gate in dhcpv4handlereply(): the router option calls netifipv4setgw() and the DNS option calls dnsresolvereconfigure(). A single accepted datagram can thus repoint the device's default gateway and resolvers at attacker-controlled addresses, redirecting its traffic; during RENEWING or REBINDING a forged DHCPACK re-binds the lease with attacker-chosen parameters and a forged DHCPNAK removes the address and restarts configuration.
The fix draws a fresh sysrand32get() value at each point where a transaction begins — entering SELECTING, RENEWING and REBINDING, and at the INIT/INIT-REBOOT entry taken when an interface with a lease goes down — while REQUESTING and DECLINE keep the identifier of the exchange they belong to, as RFC 2131 requires. As a side effect the client also no longer discards a slow server's offer after retransmitting a discover, and the initial-discover backoff now draws its own randomness instead of deriving it from the identifier.
Affected Software
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
An attacker who learns a client transaction identifier and can send DHCP replies to the client can exploit it. A host on the same network segment can observe the boot-time broadcast DHCPDISCOVER, while a DHCP server or relay on a network the device previously joined may also have learned an identifier.
What reply validation does the client perform?
The client accepts a BOOTP reply when the operation, transaction identifier, and client hardware address match. The DHCP UDP callback permits any remote address and port, and the described validation does not check the server identifier or reply source address.
How can I determine whether a client is exhibiting the vulnerable behavior?
Inspect DHCP traffic from the client. A RENEWING or REBINDING exchange using the same transaction identifier previously exposed in its boot-time DHCPDISCOVER indicates the described identifier reuse behavior; identifiers used for later exchanges may also advance predictably by one.