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.
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 valid configuration.
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.
Thanks, /mjthttp://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=689832Testing 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*.
-Dave