The makers of the internet's most popular open source DHCP program have warned that it's vulnerable to hacks that allow attackers to remotely execute malicious code on underlying machines. The flaw, which is present in Internet Systems Consortium's DHCP versions prior to 3.1-ESV-R1, 4.1-ESV-R2, and 4.2.1-P1, stems from the …
Wonder if any home routers effected
I wonder how many how routers are effected, suppose its one way to find out if there fully open source complient or if they snuck the code in there and said nothing.
But it's always the case, if i was on a totaly secure computer then you wouldn't be reading this now.
Probably not many
Very few routers use ISC DHCP. Almost all of them use a smaller, more feature-ful open source utility (dnsmasq) which does not only DHCP but also proxy DNS. Mmm. Good stuff.
Home routers usually, if they run a Linux-based software stack, use something along the lines of udhcpd, which is part of Busybox, not ISC dhcpd.
It is a serious dilemma however, and affects any system running the vulnerable versions of ISC dhcpd, whether they be *BSD, Solaris, Mac OS X or Linux. Thankfully, one that has been detected, and can be easily patched.
It's a worse problem for DHCP servers that are likely to face untrusted computers; home routers are likely only going to see people who the owners have permitted to access the network, or people who have brute-forced their way in over wifi. The latter bit is the only major concern to router makers.
Probably *very* few.
TFA is unclear on this point, but the problem lies with the DHCP client and not the server.
BTW; DNSMasq is also an actual name server as well as a DNS cache / DHCP server. A very simple and effective one at that.
Minor point of advocacy order.
Yes, dnsmasq does two things, neither of them very well. It's more useful than the canned stuff you get in "stock" "home router" type devices. It does the baseline stuff nicely, and if that's all you want to do it's peachy fine. As soon as you want to do just about anything at all more, you're SOL. So it's sadly not nearly useful enough for me. As mundane as ISC's code is, it is amazingly versatile, both their DNS and DHCP implementations. No need to slag it for that.
But anyway, this flaw is in the client, not the server, so the discussion oughtn't arise. The real question is whether you trust your network; if there's a possibility it might host rogue servers (that almost by definition the admin _didn't_ put there, so it's a question of what sort of other people have access) you need to update the ISC DHCP _clients_ on it. So that probably starts with your laptop.
Compromised DHCP server
Wouldn't they have to compromise your DHCP server first? If your DHCP server can't be trusted then you are in a whole heap of trouble.
DHCP server software can be installed on almost any device on a network. When a new client boots it broadcasts to find a DHCP server and it will usually talk to the first one that responds so someone with malicious intent who has access to the network may be able to exploit this. I expect there are methods of network infrastructure security that would mitigate this (Cisco's Port Security perhaps?) but I'm not really qualified to comment on that.
What I do know is that we did "have some fun" diagnosing the appearance of 192.168.x.x addresses on our domain when, unbeknown to us in IT, some numpty plugged an Airport into an office network socket because he wanted to wander around his department with his personally owned Mac using our corporate network wirelessly. By default the device was dishing out DHCP addresses as if it were serving a private network and a number of machines picked them up due to their proximity on the network.
Ian McNee is talking bollocks as usual...
...as pointed out by nearly everyone else, it's the client that's affected...doh!
Titles are for fools
I know what you mean, many readers here have to deal with students who want to do the same thing, I've even seen a BThomehub plugged in because the user thought that they needed it to get the internet.
Most home routers that run a Unix-like OS, are using dnsmasq to provide DHCP. dnsmasq is a lot smaller than ISC DHPCd, which these days is quite a large daemon process. And dnsmasq also provides a lot of other useful services, including a DNS cache.
It's fairly unlikely that most home routers are affected. As others have already mentioned most home routers tend to use Simon Kelley's dnsmasq for their DHCP/DNS roles.
Secondly the flaw is in the dhclient program, not dhcpd. So it's "Unix-a-like" client machines (OSX being an exception, since Apple don't use ISC dhclient) that are vulnerable rather than the DHCP servers themselves. In a corporate environment this only becomes a problem if your DHCP server is compromised to send maliciously crafted hostnames to clients, or if you have a rogue malicious dhcp server on your network doing the same thing. The first scenario can be mitigated by making sure that the DHCP server is up-to-date and secure. The second scenario can be prevented by ensuring that layer 2 ACLs in the network prevent DHCP requests/responses to/from anything other than your official DHCP server(s).
The most likely form of compromise is when connecting to an unknown "free public wifi" type wireless network with a "unixy" box. The DHCP server on that network can send you a maliciously crafted hostname attribute containing shellcode. At that point it's game over since dhclient necessarily runs as root!
Badly written story misses the main point of the vulnerability
It's the DHCP CLIENT that's affected, not the server. It's saying if you have clients running ISC dhcp and someone pops into your network with a rogue dhcp server, they can compromise your client machines.
This is a pretty specific flaw though, as neither Windows nor OSX uses the ISC client, and so are not affected by this vulnerability.
The article reads like a filler piece from the computer pages of the Telegraph, not a useful update in a tech journal (even one as Red-Topped as El Reg). In fact, the Sophos article linked in TFA is more like the article I would have expected to find here.