Bug#690889: udhcpc always returns a domain of "bad" when receiving a valid dhcp ack packet
On 10/19/2012 12:20 PM, Michael Tokarev wrote:
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.
I think that rejecting valid and allowed values seems an overreach
especially when there is no consistency with the intention of the
"validation" as is mentioned in the code comment. IMHO, It seems not so
much a questionable behavior as an incorrect one.
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 reasoning seems strongly speculative. If the value in the dhcpd
config is valid and the protocol allows for setting the value to a
domain which has the root explicitly included then it seems like the
validation as to the usability of the domain for any particular end
consumer should be left to that end consuming software. In this case,
the previous behavior of the config resulted in perfectly usable
debian-installer execution and a functional system.
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.
If the worry is about "suprizes" I think it may be worth noting that
this new "validation" behavior was quite a surprise to me in that the
action taken by udhcpc is not described in any documentation that I have
seen nor is the action reported as a syslog event nor is a message sent
to stderr nor is a non-zero return value emitted at execution denoting
any failure in the normal execution of the program. I fail to see how
summary judgment about how I should configure my dhcpd daemon by
unrelated parties should break a previously working and still provably
I'd say, for now at least, -- fix your DHCP once and for all and
be done with this issue.
My dhcp isn't broken (with regard to this issue) as long as it sends a
valid domain as the argument to the DOMAIN_NAME field.
"udhcpc: sanitize hostnames in incoming packets. Closes 3979."
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.
The result is a basic change in the functionality of debian-installer
and seems something that *at a minimum should be clearly documented*.