So Lurene is mad at me, me being Matt W. The reason for this is the following conversation.

Me: Hey you guys see the US-CERT notice on ISC dhclient overflow?
Lurene: Yup, working on coverage right now for release today.
Lurene: You do know this vuln is awesome right?
Me: How so?
Lurene: Well its in every major linux/bsd/etc distro, and those guys patch process and auto-update tools suck. Everyone will be vulnerable for a long time.
Me: Ok, but its local network only. (Me checks my Ubuntu box for an update, not there yet, ...) (Me also checks my mac real quick, sweet doesn't run dhclient)
Lurene: Yeah, like hotel network, or conferences......
Me: Oh I get it, you want play with your toys at Defcon
Lurene: Your words not mine, but my exploits already works..... and with all the Windows Vulns and firefox vulns no one is writing about this one....
Me: (Quickly returns to desk patches vuln, by hand, rebuilds dhclient, checks logs)
Me: (While my inner evil really enjoys the idea of using this at defcon, I think it makes for a much better blog post, which is why Lurene, wrote the following blog post that I am now editing)

Lurene's Blog Post with Edits:
I really didn't want to write this blog entry. This whole bug seemed to go by without a whisper, and I was really hoping it'd stay that way. I feel like I'm taking away my own toys. The dhclient bug CVE-2009-0692 is classic stack based buffer overflow in a simple memcpy that allows for easily gaining code execution. Additionally, it affects a lot of different distro's and will probably take people a long time to patch it.

Here's a run down of the bug.

Vulnerable code was:

memcpy (netmask.iabuf, data.data, data.len);netmask.len = data.len;

Patch was:

memcpy (netmask.iabuf, data.data, 4);

Seriously. That's it. Large subnet option in a DHCP ACK packet. Netmask.iabuf is on the stack.

Living in front of it on the way to ret are a few pointers and structs:

int i;struct data_string data;struct option_cache *oc;struct envadd_state es;

You can ignore es I think, set *oc to a readable location, then you get to mess with data. That's cool because AFTER it copies the netmask (AFTER!) it checks the length to see if data.len value is the same as the size of the IP address. As you're walking up the stack, just whack that size with 4 and roll on along to RET. Done deal. There are a couple other places you need to put in a readable address, but that's easy.

Now all the linux box on the network segment belong to you. Now you just need to have it rerun dhclient to get an IP and send you back a shell, or hotpatch the process, set the stack up to return to your callback shell, then ret back to main. Tada.

(Ed note: If you haven't already patched your laptops, VM images, servers, etc you should especially if you run this on your laptop and are going to defcon or any fun conference. Since the airport has WiFi, SouthWest has WiFi on the plane, the conference has WiFi, and so do people with heavy backpacks..... )

Also if you're running the VRT rules this vulnerability is already covered GID 3 SID 15700