Bug#690889: [PATCH] udhcpc: allow trailing dot in names
Commit 7280d2017d8075267a12e469983e38277dcf0374 (fix for #3979,
which is CVE-2011-0997) added sanitization of some strings
returned from DHCP server. And one of the things it now
disallows is a trailing dot, for, for example, domain names
like "host.example.com." -- this is now treated as invalid.
However, apparently, some installations use this sort of
names, and especially, other implementations (ISC DHCP client
for example) allows such trailing dots too.
It is arguable corner case - for example, it is unknown how
much 3rd party software parses /etc/resolv.conf - where the
domain name ends at - and how many software does not expect
trailing dot to be there, and will segfault or do other bad
things if it is present.
But being consistent appears to be a good idea too, or else
udhcpc will be blamed for being buggy in situations where
other popular software works.
Also, the comment around this function especially says there
is no reason to perform very strict checking, and especially
mentions trailing dot.
And I really don't know how serious this issue is in practice --
ie, how many places has this trailing dot configured in their
setup, and how do this on purpose instead of by mistake.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
---
networking/udhcp/dhcpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/networking/udhcp/dhcpc.c b/networking/udhcp/dhcpc.c
index f72217c..01a9bf8 100644
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
@@ -187,6 +187,8 @@ static int good_hostname(const char *name)
return 0;
if (!name[0])
return 1;
+ if (name[0] == '.' && !name[1]) /* trailing dot */
+ return 1;
//Do we want this?
//return ((name - start) < 1025); /* NS_MAXDNAME */
name++;
--
1.7.10.4
Reply to: