Bug 128605 - [patch] dhclient(8) - security issue
Summary: [patch] dhclient(8) - security issue
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-05 12:10 UTC by Raffaele De Lorenzo
Modified: 2017-12-31 22:29 UTC (History)
0 users

See Also:


Attachments
file.diff (2.13 KB, patch)
2008-11-05 12:10 UTC, Raffaele De Lorenzo
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Raffaele De Lorenzo 2008-11-05 12:10:03 UTC
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
    127.0.0.1    foo

client (B)
2) run dhclient <interface to "A">
Comment 1 Remko Lodder freebsd_committer 2008-11-05 18:54:26 UTC
Responsible Changed
From-To: freebsd-bugs->remko

I'll take it.
Comment 2 Remko Lodder freebsd_committer 2008-11-05 18:54:41 UTC
Responsible Changed
From-To: remko->secteam

Reassign to security team
Comment 3 Dag-Erling Smørgrav 2012-09-10 21:14:11 UTC
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.

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Comment 4 Dag-Erling Smørgrav 2012-09-10 21:31:01 UTC
Dag-Erling Sm=C3=B8rgrav <des@des.no> 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".

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Comment 5 Dag-Erling Smørgrav freebsd_committer 2012-09-11 13:33:03 UTC
Responsible Changed
From-To: secteam->freebsd-bugs

Not a security issue.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:29 UTC
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