Live data from Hacker News

Shellshock DHCP Remote Code Execution – Proof of Concept

trustedsec.com

31–40 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#32
I think one of the things Heartbleed PoCs did really well was show the result for the end user. Most people aren't going to know what any of this stuff means. Can we come up with a really straight forward explanation in laymans terms as to what this means for the average Internet user?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#33

FreeNAS (based on FreeBSD 9.2) has a vulnerable bash. I have 9.2.1.7.

FreeNAS doesn't use bash as /bin/sh by default or as root shell unless you've set it yourself (which some users do: http://forums.freenas.org/index.php?threads/replacing-standa...)

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#35
Yeah, I don't think anyone has grasped the extent of how dangerous this vuln is -- was it released a little prematurely? is it still in "embargo"?

This is hundreds of times worse than heartbleed in terms of scope/attack surface for modern servers... (I say hundreds of times worse because heartbleed was scrape-some-data-till-you-get-private-keys-and-watch-communication, where this is just get-yourself-a-shell-and-pwn-the-machine)

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#36
post #24

Earlier quoted context omitted.

Does NetworkManager completely obviate the need for the DHCP binary to call shell scripts? Those scripts often exist because if the sysadmin needs something special to happen on DHCP, this is where he sets it. It's not "DHCP scripts get run by/are shell scripts," it's "DHCP binaries are prepared to call out to external scripts." I've had to write these shell scripts (using ksh, since OpenBSD, so those are safe).

Well, Network Manager for starters is a binary and not a shell script like the dhclient-script.

dhclient is a binary on Linux and OpenBSD.

It calls shell scripts, because, like I said in the comment you replied to, sometimes sysadmins need very specific things to happen when the machine gets a DHCP lease.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#38

So, an exploit using off-the-shelf software. Just awesome.

Well, yes. If you were going to exploit CGI scripts you'd likely use wget or curl instead of coding an HTTP client from scratch so why is this suprising?

It's a little surprising because I'm tempted to classify this one as 'requires 0 lines of code'.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#40

Note that this will affect devices without listening services. Embedded devices are very likely to be affected for a long time. A note for those trying to reproduce the PoC (as I was yesterday) - ISC's DHCP server only sends client-requested options by default, though this can be overridden [1]. tftpd [2], the software used in the PoC, is likely the easiest way to demo the vulnerability. [1] http://linux.die.net/man/…

I reproduced it with dnsmasq as well; just set up a server with the following options. eth2 is the network adapter that I was using for the test network, and I picked the 10.0.10.0/24 prefix for this particular network.

  interface=eth2
  dhcp-range=10.0.1.100,10.0.10.200,12h
  dhcp-option-force=114,() { :; }; echo "hi"
Then on the target system (an Ubuntu system using ifupdown for configuration), I just configured eth0 for dhcp:

  iface eth0 inet dhcp
and ran:

  sudo ifdown eth0 && sudo ifup eth0
Unlike some of the other exploits, this one affects Debian and Ubuntu. Debian and Ubuntu use dash as /bin/sh, so many things that just use /bin/sh (such as the system() function, lots of shell scripts, etc) aren't affected like they are on other Linux distros.

But dhclient calls dhclient-script to execute various hook scripts, and dhclient-script uses #!/bin/bash and is thus vulnerable.

On my particular Debian system, it doesn't look like NetworkManager based DHCP is affected, as it doesn't call the dhclient-script. It does call various scripts in /etc/network/if-*.d/, but none of the ones that I have installed use bash, they all use sh. However, if I deliberately put a bash script in there, and attach it to the network with the rogue DHCP server, it does get passed the bad environment variable (though on my Debian system I've already updated Bash so I just get the error message rather than the exploit).

So yeah, there are a a lot of ways for a stray Bash script to cause problems here.

Post reply on HN