Bug#690889: udhcpc always returns a domain of "bad" when receiving a valid dhcp ack packet
On 19.10.2012 11:05, Michael Tokarev wrote:
> On 19.10.2012 00:49, Dave Rawks wrote:
>> Package: udhcpc
>> Version: :1.20.0-7
>> Severity: normal
>> Tags: d-i
>>
>> udhcpc always returns a domain of "bad" when receiving a valid dhcp ack
>> from an upstream dhcp server. To reproduce first create a shellscript to
>> dump all of the variables set by udhcpc uppon successful receipt of a lease:
>
>> I've tcpdumped both the client and server side of the dhcp exchange and
>> wireshark decodes the full ack packet as a valid dhcp/bootp ack AND includes
>> the correct domainname as configured to be sent on the server.
>
> Please tell us WHICH domain name is treated as "bad".
>
> You're hitting this fix for CVE-2011-0997:
The new function to verify name validity introduced to fix CVE-2011-0997
disallows names with trailing dots. So any domain name ending in a dot
is rejected and is substituted with "bad" as subject says.
This is questionable - both the usage of names with trailing dot in this
context (it is not entirely DNS anymore, where trailing dot is obviously
allowed and perfectly valid), and rejecting of such names.
On one hand, we should not use such name (with trailing dot) without stripping
the dot first, since, I guess, other components of the system (or installer)
may break not expecting this trailing dot. Currently, udhcpc does not do
this.
On another hand, modifying options does not sound good.
The comment in the change says:
+/* We don't need to be particularly anal. For example, allowing _, hyphen
+ * at the end, or leading and trailing dots would be ok, since it
+ * can't be used for attacks. [...]
but actually it does NOT allow neither leading nor trailing dots.
I disagree, to me neither of these is good since it can lead to,
at least, surprizes, -- in other software which is not expected
to see these dots. And this is exactly what this issue is about:
CVE-2011-0997 says about surprizes when malicious DHCP server is
sending not entirely correct replies.
I'd say, for now at least, -- fix your DHCP once and for all and
be done with this issue.
Thanks,
/mjt
> http://git.busybox.net/busybox/commit/?id=7280d2017d8075267a12e469983e38277dcf0374
> "udhcpc: sanitize hostnames in incoming packets. Closes 3979."
> https://bugs.busybox.net/show_bug.cgi?id=3979
> https://bugzilla.redhat.com/show_bug.cgi?id=689832
>
>> Testing with isc-dhcp-client also yields a successful lease with the correct
>> domain name set.
>
> So the fix in busybox is different than implementd in isc-dhcp.
Reply to: