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: |
|
Description
Raffaele De Lorenzo
2008-11-05 12:10:03 UTC
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 |