Bug 128605
| Summary: | dhclient(8) - security issue | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Raffaele De Lorenzo <raffaele.delorenzo> | ||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed Not Accepted | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Responsible Changed From-To: freebsd-bugs->remko I'll take it. Responsible Changed From-To: remko->secteam 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. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no 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 Responsible Changed From-To: secteam->freebsd-bugs 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 |
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">