[unisog] Mac OS X 10.4.x "DHCP client sometimes remains BOUND aftersending DHCPDISCOVER" bug

[Irwin Tillman]

Keith Neufeld <keith.neufeld at wichita.edu> wrote:

> Where in the RFC does it state
> that the server is privy to the current state of the client's state
> machine, or permitted to behave based on educated guesses as to that
> state?


When the server receives a DHCPREQUEST, the RFC requires the server
to respond differently to the client based upon whether the client
is in the INIT-REBOOT, SELECTING, RENEWING, or REBINDING state.

In 4.3.2 (paragraph 1), it says that if the message contains a Server Identifier
option, the message is in response to a DHCPOFFER message.  (So in this
case, the server knows the client is SELECTING.)

That leaves INIT-REBOOT, RENEWING, and REBINDING states
to distinguish.

In 4.3.2 (DHCPREQUEST generated during INIT-REBOOT state),
it says the server determines the client is in INIT-REBOOT state
 based on the contents of the 'giaddr', the
'requested IP address' option, and a database lookup.

That leaves the RENEWING and REBINDING states to distinguish.

The contents of the DHCPREQUEST sent in RENEWING and REBINDING states are the same,
except that the former is unicast while the latter is broadcast.

How does the server distinguish them?
Well, if giaddr is non-zero, the servers know it the packet must have been broadcast
and relayed by a BootP Relay Agent, so the client is REBINDING.

But if giaddr is zero, the server does't know whether the client is RENEWING or
REBINDING while on the same subnet as the server; to distinguish,
the server would need to see the DHCPREQUEST's IP destination address.
That field may not be available to server, depending on the implementation.
(E.g. in the common sockets API available at the time the spec was written,
the packet's IP destination address generally was not available to the server.)

Figuring out the state of the client that sends a DHCPREQUEST matters,
because the RFC requires the server to respond
differently to the client based upon the state the client is in:

- In 4.3.2 (DHCPREQUEST generated during INIT-REBOOT state), the server is
  required to respond to the client with a DHCPNAK under some circumstances.
  (For example, when the requested IP address is on the wrong network, or is not "correct".)

- In 4.3.2 (DHCPREQUEST generated during RENEWING state), the server doesn't
  perform those checks (or respond with a DHCPNAK if they fail); instead it is
  require to trust 'ciaddr'.

- In 4.3.2 (DHCPREQUEST generated during REBINDING state), the server is
  required to check 'ciaddr' for correctness before replying.


My point is that the RFC does indeed expect the server to figure out
the state of the client in some places, and behave differently.


> If a DHCPDISCOVER packet from a MAC address automatically means that
> the MAC address relinquishes its claims on any lease(s) it has, then
> there's a trivial new way to DoS an entire subnet--just watch
> broadcast traffic long enough to collect MAC addresses, then  
> broadcast DHCPDISCOVER messages with spoofed MACs.  Poof!  All the
> leases are invalidated--and best of all, the real clients don't even
> know it!
> I know that DHCP doesn't provide strong integrity against MAC  
> spoofing; but the consequences of this claim make DoSing just a
> little too easy.


Yes, DoSing DHCP is easy enough regardless...

One may listen to broadcast DHCPREQUESTs sent by clients in SELECTING state
to get a pretty good idea of many leases, then send a 
bunch of DHCPRELEASE messages to the servers.  


Irwin Tillman / OIT Network Systems / Princeton University