+++ This bug was initially created as a clone of Bug #362453 +++
From redhat, see original bug for source:
Sebastian Krahmer of the SUSE security team noticed that DHCP clients fail to
sanitize certain values supplied by DHCP servers during the DHCP communication.
The example of such value is hostname configured on the DHCP client. Various
scripts assume hostname is trusted and do not sufficiently escape or quote it.
Malicious DHCP server can use this to execute arbitrary code on the DHCP client
by supplying a specially-crafted hostname.
This issue affects dhcpcd as well, fixed in 5.2.12.
Upstream links a 'CVE-2011-966', not sure if this was a typo or if two identifiers were assigned for dhcpcd and ISC separately.
Dhcpcd 5.2.12 is in the tree.
(In reply to comment #1)
> Dhcpcd 5.2.12 is in the tree.
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
if i launch dhcpcd eth0 it assign me an address but when i verify with ifconfig eth0 i see the previous address.
If i modify my /etc/conf.d/net at startup dhcpcd works
Stable for HPPA.
x86 stable. Thanks
Marked ppc stable.
ppc64 stable, last arch done
Thanks, everyone. GLSA request filed.
should I remove all older versions of dhcpcd?
(In reply to comment #12)
> should I remove all older versions of dhcpcd?
Yes, please, thank you.
All versions of dhcpcd < 5.2.12 have been removed.
dhclient in ISC DHCP 3.0.x through 4.2.x before 4.2.1-P1, 3.1-ESV before
3.1-ESV-R1, and 4.1-ESV before 4.1-ESV-R2 allows remote attackers to execute
arbitrary commands via shell metacharacters in a hostname obtained from a
DHCP message, as demonstrated by a hostname that is provided to
This issue was resolved and addressed in
GLSA 201301-04 at http://security.gentoo.org/glsa/glsa-201301-04.xml
by GLSA coordinator Stefan Behte (craig).