This is a security problem that I founded in the dhclient program. If you configure a dhcp-server (I tested it with "isc-dhcp30-server" from ports) with a particular Server Id ("option dhcp-server-identifier" in "dhcpd.conf") as "localhost" (127.0.0.1) the DHCP response (ack) packet will be sent from server to client identified by the localhost ip address. In this situation the client doesn't check the server identifier and always accepts the "ack" messages.
RFC2131 needs a valid IP address as Server Identifier: (from RFC2131: "The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to to accept any of its network addresses as identifying that server in a DHCP message. To accommodate potentially incomplete network connectivity, a server MUST choose an address as a 'server identifier' that, to the best of the server's knowledge, is reachablefrom the client.")
I saw the dhcp client made by Darwin (Leopard), Windows Vista and Darwin Iphone OS respect the RFC2131 "server-identifier" and they rejected all "ack" messages identified by "127.0.0.1"; in reply FreeBSD 7, Linux and Windows XP/2000 doesn't respect it. I couldn't test it with other OSs.
Fix: I patched the dhclient to solve this problem.
Patch attached with submission follows:
How-To-Repeat: If you use the "isc-dhcp30-server" from port:
dhcp server (A):
1) insert inside "dhcpd.conf" a server identifier like this:
option dhcp-server-identifier foo
you must insert this line in your /etc/hosts
2) run dhclient <interface to "A">
I'll take it.
Reassign to security team
Picking up the thread after four years...
First of all, DHCP clients have no choice but to trust whatever answer
they get, so the fact that a server misconfiguration can lead a client
into trouble shouldn't come as a surprise. The issue you've highlighted
is just one of a million ways the server can feed the client incorrect
information, and your patch will only catch one of a million incorrect
server identifiers (or, to be precise, 24 million out of 4 billion).
I don't see how this is a security issue, either. The only consequence
of an incorrect server identifier is that the client will be unable to
refresh or renew its lease, and will have to perform DHCP discovery
again when the lease runs out.
As for your patch - as previously mentioned, it only catches one of
nearly 2^32 possible incorrect identifiers. For instance, it will not
reject DHCP answers where the identifier is the same IP address that the
client is being assigned, or an IP address which is in use by the client
on another interface, or a multicast address, etc.
Furthermore, it will only work on little-endian systems. The correct
test would be ((ntohl(addr.s_addr) & 0xff000000) =3D=3D 0x7f000000) or more
succintly (ntohl(addr.s_addr) >> 24 =3D=3D 0x7f); a more pedantic solution
would use the various constants and macros defined in <netinet/in.h>.
Finally, one could argue that the cure is worse than the disease, since
the client will reject the answer and eventually time out, ending up
with no IP address, when it is entirely possible that the answer it
received was actually correct, apart from the server identifier.
Dag-Erling Sm=C3=B8rgrav - email@example.com
Dag-Erling Sm=C3=B8rgrav <firstname.lastname@example.org> writes:
> information, and your patch will only catch one of a million incorrect
> server identifiers (or, to be precise, 24 million out of 4 billion).
> As for your patch - as previously mentioned, it only catches one of
> nearly 2^32 possible incorrect identifiers.
I must be tired. The correct numbers are "16 million out of 4 billion"
and "2^24 out of 2^32".
Dag-Erling Sm=C3=B8rgrav - email@example.com
Not a security issue.
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped