full-disclosure - Re: ISC DHCP Client [3.0.x to 4.2.x] Arbitrary Command Execution (CVE-2011-0997)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <4D9CD935.2342.55B72E25@nick.virus-l.demon.co.uk>
Date: Thu, 07 Apr 2011 09:20:53 +1200
From: Nick FitzGerald <nick@...us-l.demon.co.uk>
To: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: ISC DHCP Client [3.0.x to 4.2.x] Arbitrary
 Command Execution (CVE-2011-0997)

coderman to Valdis.Kletnieks:

> > Otherwise if a valid dhcp server hands you foo.bar.baz.example.com your hostname
> > just became foobarbazexamplecom - whoops.
> 
> a DHCP server should not reply with a FQDN as hostname.
> 
> hostname 'foo' at domainname 'bar.baz.example.com' is legit though...

So Valdis' complaint about the "fix:

   new_host_name=${new_host_name//[^a-zA-Z0-9]/}

still partly stands.

They should at least have gone with:

   new_host_name=${new_host_name//[^-a-zA-Z0-9]/}

as hyphens are valid in host names.

Whether the code should gracefully handle itself in misconfigured 
environments, or more, to what extent it should, is ultimately up to 
the developers, so they can quibble over the dot character...

Regards,

Nick FitzGerald

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/