This CVE was fixed in dhcpcd 5.2.12 which was released in April 2011. Since this is the latest bugfix release of the 5.2 branch, we should update to it. This version already exists in Cauldron. "dhcpcd before 5.2.12 allows remote attackers to execute arbitrary commands via shell metacharacters in a hostname obtained from a DHCP message."
Hi, thanks for reporting this bug. As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
CC: (none) => ennael1, thierry.vignaud
Submitted to updates_testing. Assigning to QA. Advisory: ======================== Updated dhcpcd package fixes security vulnerability: dhcpcd before 5.2.12 allows remote attackers to execute arbitrary commands via shell metacharacters in a hostname obtained from a DHCP message (CVE-2011-0996). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0996 ======================== Updated package in core/updates_testing: ======================== dhcpcd-5.2.12-1.mga1 from dhcpcd-5.2.12-1.mga1.src.rpm
Assignee: bugsquad => qa-bugs
No PoC's
(In reply to comment #3) > No PoC's What does that mean? Do you need something from me?
No David, thanks. It is just a note that there doesn't appear to be any public exploits (proof of concepts) to test the CVE's.
Looks like a good example for producing a poc here. https://bugzilla.novell.com/show_bug.cgi?id=675052 Working on a test for i586 right now.
CC: (none) => davidwhodgins
Created attachment 1618 [details] Config for poc I use a fixed ip on my host, disabled dns in my router, and used the attached config for the poc. In a VB guest, I can confirm ... grep name /var/lib/dhcp/dhclient-eth0.leases option host-name "mageiavb.hodgins.homeip.net\$(id>>/tmp/foo)"; option domain-name "hodgins.homeip.net\$(id>>/tmp/foo)"; However, the ifup script doesn't use these values, so the command doesn't get executed. The ifup script does a reverse lookup of the ip address, to get the name. So Mageia systems are not susceptible to the bug. I'll install the testing version now, to ensure the command doesn't get passed.
I just realized I've been testing with the wrong packages. I was using dhcp-server and dhcp-client, which are installed by default. I'll remove those and retest with dhcpd.
Sorry for the confusion. I'm now using dhcp-server on the host with the config from attachment 1618 [details], and dhcpcd in the guest. In /etc/dhcpcd.conf, I have added env force_hostname=YES In ifcfg-eth0, I have DHCP_CLIENT=dhcpcd On a reboot, the ip address is being set, but the command in the host/domain name is not getting executed. I then installed the update, and confirmed the ip address was set correctly. Although I could not recreate the bug, I'm going to call testing on i586 complete for the srpm dhcpcd-5.2.12-1.mga1.src.rpm While I would prefer it if I could recreate the bug, to confirm the update fixes it, I'm not going to hold up this update, as anyone using wireless could be susceptible to the problem, which makes this a high priority fix.
CC: thierry.vignaud => (none)
We still need x86-64 testing, to confirm the updated dhcpcd package still works. Keep in mind this is not the dhcp-client installed by default.
# ifdown wlan0 Reloading vnstatd configuration: [ OK ] # ifup wlan0 Determining IP information for wlan0...dhcpcd[14397]: version 5.2.12 starting dhcpcd[14397]: wlan0: rebinding lease of 192.168.2.63 dhcpcd[14397]: wlan0: acknowledged 192.168.2.63 from 192.168.2.1 dhcpcd[14397]: wlan0: checking for 192.168.2.63 dhcpcd[14397]: wlan0: leased 192.168.2.63 for 86400 seconds dhcpcd[14397]: forked to background, child pid 14479 done. Reloading vnstatd configuration: [ OK ] Testing complete x86_64
Validating. See Comment 2 for the advisory. Could sysadmin please push from core/updates_testing to core/updates Thank you!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => All
Validating. SRPM: dhcpcd-5.2.12-1.mga1.src.rpm Advisory ======================== Updated dhcpcd package fixes security vulnerability: dhcpcd before 5.2.12 allows remote attackers to execute arbitrary commands via shell metacharacters in a hostname obtained from a DHCP message (CVE-2011-0996). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0996 ======================== Could sysadmin please push from core/updates_testing to core/updates Thankyou!
David, please don't do that. It wastes my time and you can't possibly validate your own update anyway!
Testing complete on i586 - Comment 9 Testing complete on x86_64 - Comment 11 You usually validate when it's done, but you didn't, so I was a bit confused by that, but I guess you were just doing it in two separate comments this time and I caught you in the middle. Let's not have a fight about it :o)
The few minutes in between posting comment 11 and comment 13 was spent restoring things to normality before Validating. I'm sure a 2011 update can wait for the 9 minutes I spent doing so. Either way, you cannot validate your own updates.
Claire, I don't have a problem with that. I didn't know that was the policy, but it's a sensible policy. I did know that you can't *test* your own updates, so I left that to you and Dave, even though I've tested and validated some updates built by others. So we understand each other and are on the same page now. If we need to discuss this any further, we can do it outside of Bugzilla. Thanks for all your work!
update pushed
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED