
Shellshock DHCP Remote Code Execution – Proof of Concept - jeffmcjunkin
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
======
hardwaresofton
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)

~~~
ams6110
On the other hand Windows sysadmins are probably enjoying some schadenfreude
right about now.

~~~
takeda
It's mostly Linux issue because bash is there installed by default and even
/bin/sh is really bash...

For example on BSD you could technically install bash, but chances that it is
used as a shell for a services is very small.

~~~
dfc
Debian's default /bin/sh is not "really bash," it is dash. The same is true
for many embedded distros based on busybox.

~~~
mct
While this is generally true of newer Debian installations, older machines
that have been been regularly updated over the years to stable may still have
/bin/sh pointing to bash. I fixed a few of my machines yesterday to use dash.

~~~
dfc
dash changelog.Debian.gz entry from July 22nd, 2009:

    
    
      * Change the default for the system shell to dash.
      * Ship /bin/sh in the package and fix the diversion handling
        for it to make sure /bin/sh is always present.
      * Set debconf priority to high when upgrading from an existing
        system.
    

Unless the admin has--for some bizarre reason--set debconf to critical; during
one of those "regular updates" the admin would have been presented with the
following question:

    
    
      The system  shell is the default  command interpreter for 
      shell scripts.                                            
                                                    
      Using  dash   as  the  system  shell   will  improve  the
      system's overall performance. It does not alter the shell
      presented to interactive users.   
    
      Use dash as the default system shell (/bin/sh)?
    
          <Yes>      <No>

~~~
vertex-four
This assumes that the admin is administering their systems by running apt-get
update && apt-get upgrade manually, rather than some automated process.

~~~
dfc
What automated process for Debian administration is unaware of debconf?

This is a honest question. How could an automated Debian administration
process not be aware of and interact on some level with debconf?

~~~
vertex-four
Does this change default to "yes" on unattended installs? I'd assume it
doesn't, because that would be dangerous.

EDIT: Indeed, from the same changelog: debian/dash.NEWS.Debian: when upgrading
existing installations, the system shell will not be changed automatically
(closes:#539363).

~~~
dfc
Just so we are clear you would be talking about an _unattended dist-upgrade
from lenny to squeeze_? Have you done this?

Please explain how your automated Debian administration system that has been
in place since Lenny[^1] handles _unattended dist-upgrades_ without the use of
preseeding the debconf database for questions with a priority of high or
critical?

[^1]: Squeeze was February 2011, any new stable installation since squeeze
defaulted to dash as /bin/sh

EDIT: Nevermind, I answered my own question, unattended dist-upgrades from
Lenny to squeeze is not something you have any experience with: "I'm now using
Debian Wheezy, after primarily using Windows environments my entire life."
[https://news.ycombinator.com/item?id=6564610#up_6565766](https://news.ycombinator.com/item?id=6564610#up_6565766)

------
1wd
Is it just me or would it be a good time to learn a bigger lesson from
Heartbleed and Shellshock:

Minimalism is seriously a good idea. "Features" are not harmless and cost way
more than you think. Providing more flexibility or functionality than
absolutely necessary should really be considered and called out as defective,
smelly and a bad practice.

~~~
Corrado
Which brings to mind the latest push for systemd as an init replacement. :/

~~~
zorked
You will be shocked to learn that the Linux kernel is actually much bigger :/

~~~
SixSigma
Which, in itself, is another disaster.

~~~
vhost-
Erm what? Can you elaborate a bit on this?

~~~
SixSigma
Massive kernel, loads of code.

Impossible to read and understand.

------
mr_brown
I believe there will be plenty of linux NASs that will be vulnerable for the
forseeable future. NASs are usually bigger and more functional than routers,
they tend to run a more full system. Many of these for exampe run bash as far
as I remember: [http://www.amazon.com/s/field-
keywords=QNAP](http://www.amazon.com/s/field-keywords=QNAP)

~~~
syshax
Just FYI to other owners:

Synology DSM 5.0-4493 Update 5 here: it uses busybox, so not vulnerable.

    
    
        synology> which bash
        synology> which sh
        /bin/sh
        synology> which ash
        /bin/ash
        synology> ls -l /bin/sh
        lrwxrwxrwx    1 root     root             7 Jun  5 11:27 /bin/sh -> busybox
        synology> ls -l /bin/ash
        lrwxrwxrwx    1 root     root             7 Jun  5 11:27 /bin/ash -> busybox

~~~
adamfeldman
Thank you for checking out DSM! This comment saved me a bunch of time.

------
mariusz79
So now we can have

dhcp-option-force=114,() { :; }; if hash apt-get 2>/dev/null; then apt-get
update -y && apt-get upgrade -y;fi; if hash yum 2>/dev/null; then yum
update;fi;

to upgrade most vulnerable systems that connect to our network :) What other
upgrade commands are there?

~~~
mariusz79
It would be even better if we could create a community driven script hosted at
some trusted location that would basically download info how to upgrade
specific distribution, and execute that script on the vulnerable system.. so
something like wget fix && chmod +x fix && ./fix :)

~~~
neersighted
Then what would happen if someone compromised the fix?

------
syshax
Thanks for the info.

Has anyone tried this with an OS X client to see if it behaves like the Linux
system in the article? I know OS X bash is vulnerable to the exploit, but I
don't know if their DHCP system handles environment variables in an
exploitable way.

~~~
somemacsysadmin
OS X doesn't use Bash for configuring DHCP, so it's not vulnerable. All of
that is done in the kernel on Macs.

------
iLoch
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?

~~~
bx_
[http://shellshock.co.za/](http://shellshock.co.za/)

i thought this was pretty straightforward

~~~
justrandomanon
offtopic

why do people use custom scrolling behaviour? it's always horrible

------
SchizoDuckie
Holy shit that is scary. Package this on an android phone and you can wreak
havoc on any random network

~~~
orblivion
Assuming it's a network full of machines who haven't bothered updating yet.
EDIT: right?

~~~
dmethvin
Um, "haven't bothered"? Think about all the _Linux /Unix_-based devices that
could be affected here, it's in the millions. Do you run a local server on
your box? How about your Linux-based router? Has it been patched yet? Why not,
it's been more than _24 hours_ now.

~~~
josteink
> How about your Linux-based router?

In the embedded world, people rarely run full GNU userland utils. They're
extremely big and bloated, and embedded devicse needs maximum bang for buck.
Therefore most of them comes with busybox, which besides being incredibly
compact also is 100% unaffected.

Same goes for Android/Linux-based phones. Most don't come with a proper shell
at all, and those who do, usually have busybox.

~~~
orblivion
> Same goes for Android/Linux-based phones. Most don't come with a proper
> shell at all, and those who do, usually have busybox.

If this is true, there's been a fair amount of paranoia on HN that has gone
sadly unanswered with corrections.

------
technimad
Another reason to implement DHCP snooping on your network gear.

~~~
smutticus
That's what I was thinking. If you let random machines on your network hand
out DHCP addresses you've got bigger problems.

------
jeffmcjunkin
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/5/dhcpd-
options](http://linux.die.net/man/5/dhcpd-options) (search for "dhcp-
parameter-request-list")

[2] [http://tftpd32.jounin.net/](http://tftpd32.jounin.net/)

~~~
makomk
Thankfully embedded devices are less likely to have bash installed than
desktop or server systems, or this would be quite nasty.

~~~
tdicola
Are smaller shells like busybox affected though? I bet a lot of routers run it
(I know mine with OpenWRT does).

~~~
masklinn
The problem is very specific to bash and bash only (a hacky feature via
environment variables so shells can inherit their parent's functions)

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

~~~
tokenizerrr
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?

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

~~~
zobzu
its pretty much the same for CGIs, its a one liner. theres other exploits like
that. it happens :)

------
zurn
So is the default dhclient conf vulnerable in any of the Linux distributions
using bash for /bin/sh (eg CentOS/Fedora)?

edit: According to one poster on Stackexchange, Debian/Ubuntu may be vulerable
despite not having bash for /bin/sh: "What's more, on Debian (and possibly
many of its myriads of offsprings like Ubuntu), which uses dash as /bin/sh,
dhclient-script is explicitely shebanged to /bin/bash, and it does seem to
contain a bashism, too"
([https://security.stackexchange.com/questions/68156/is-
connec...](https://security.stackexchange.com/questions/68156/is-connecting-
to-an-open-wifi-router-with-dhcp-in-linux-susceptible-to-shellshoc))

------
exploit
I've tried to replay this attack in VM environment using Debian, but no luck.

option dhcp_114_FW_URL code 114 = text; option dhcp_114_FW_URL "() {
ignored;}; cat /etc/shadow > /tmp/shadow"

or

option domain-name "() { :;}; cat /etc/shadow > /tmp/shadow";

not working.

dhcpdump says that option sends correctly: OPTION: 53 ( 1) DHCP message type 5
(DHCPACK) OPTION: 54 ( 4) Server identifier 192.168.1.1 OPTION: 51 ( 4) IP
address leasetime 600 (10m) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3
( 4) Routers 192.168.1.1 OPTION: 15 ( 39) Domainname () { :;}; cat /etc/shadow
> /tmp/shadow

What could be the problem?

~~~
lambda
What were you using to configure networking on the target machine?
NetworkManager, ifupdown, something else?

I found that with ifupdown, you see the issue, as it uses dhclient which in
turn calls out to dhclient-script, which is written in bash. If you use
NetworkManager, it doesn't call dhclient-script; it does however call the
scripts in /etc/network/if- _.d, and if any of those are written in bash, then
you see the issue. None of the scripts in /etc/network/if-_.d on my system
used bash, they all used /bin/sh, so on a Debian system where that points to
dash instead of bash you're OK.

~~~
exploit
Of course I've used dhclient for this (also with -r option) with ifconfig
up/down. Not working. I've also tried to re-simlink sh to bash. Not working.
I'd like to check py script by mschwager
([https://github.com/mschwager/shellshock_poc](https://github.com/mschwager/shellshock_poc)),
may be it will be OK.

------
schwag09
I created a python + scapy poc:

[https://github.com/mschwager/shellshock_poc](https://github.com/mschwager/shellshock_poc)

I tested it with my laptop and android phone on my wifi network.

~~~
exploit
So could you get a root shell (on linux laptop)?

~~~
schwag09
Unfortunately my poc isn't working as expected. I'll continue investigating,
and keep the repo up to date.

Feel free to fork it and use it as a place to start for your own poc.

------
rsmarples
dhcpcd-6.4.7 is hot off the press, the main improvement being mitigating the
bash "ShellShock" exploit by escaping all characters as noted in IEEE Std
1003.1, 2004 Edition, 2. Shell Command Language, 2.2 Quoting except for the
space character.

Needless to say, the entire BSD family is not affected by this bug as bash is
not the default shell and to be fair a lot of Linux distributions are not
affected either. If bash is your Linux distributions /bin/sh, OR you have
applications directly calling bash, you should be telling them to get with the
times as most people have since moved on to ash, dash or busybox for more
efficient processing.

Regardless, shell is such an important in part of the system - it allows non
programmers to "do things". Thanks to the dhcpcd hook system, a user was able
to start tcpdump on hotplugged interface before dhcpcd actually started using
it during the boot process. Why he wanted to do this, I don't know, probably
for some debugging. But the point is, how would he have done this without
shell hooks?

The important thing to take away from this is don't lock yourself into one
technology - strive to be portable. dhcpcd works on many OS's, libcs, shells
and userland tools. If any of them prove faulty, swap them out - including
dhcpcd itself! But please at least tell me why you're swapping dhcpcd out so I
can improve it :)

------
hyperbovine

        curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
    

Let's hope that script does what it claims to do :)

~~~
bostik
Even if that was meant as a joke, I do hope you realise the irony.

To protect against running untrusted code in a shell, you ... run code from an
untrusted source in the shell. As root.

~~~
hyperbovine
Yes :-)

------
cpg
Wow, that is scary how a simple DHCP option can propagate like that.

Speaking of Linux-based NAS systems, Amahi systems have been updated via a
repo update that pulls the latest bash fix.

------
guest0925
Why did the quotes show up?

~~~
sambe
My first reaction too. However, it's not hard to imagine some escaping being
thrown in there at some point.

------
akkartik
Does this mean I shouldn't run dhcp servers? Or is even my laptop running a
dhcp client going to have a bad time?

~~~
jeffmcjunkin
This means that DHCP clients that use bash and have DHCP server-controlled
environment variables can have commands injected (as root) by a malicious DHCP
server.

Notably, attackers in an unhardened network can reply to DHCP clients
themselves, even if there's already a DHCP server on the network. So it's not
just the sysadmin who can exploit this, but anyone on the same network
(broadcast domain) as the vulnerable DHCP client.

~~~
akkartik
Alright, I'm shutting down my cable modem. See y'all later.

------
danielweber
I was going to do this this evening and now he's saved me the time. Thanks! :)

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

~~~
lambda
The question is, does it call bash in its dhclient-script? I took a look
through the FreeBSD source tree, and their version of dhclient-script uses
/bin/sh. As long as /bin/sh is not bash (and that script doesn't in turn call
any other bash scripts) it should be OK.

The best way to find out if you're vulnerable is by testing. It takes just a
few minutes to set up dnsmasq to serve up an exploit. Here were my settings:

    
    
      interface=eth2
      dhcp-range=10.0.1.100,10.0.10.200,12h
      dhcp-option-force=114,() { :; }; echo "hi"
    

Of course, replace that 'echo "hi"' with the exploit of your choice. In my
case, the output from dhclient would be printed on screen when restarting
networking, so 'echo "hi"' was sufficient to verify that it was being
executed.

If any bash scripts are called, with the environment variables that are set by
dhclient, then that snippet should be run. If bash is not invoked, then that
snippet won't ever run.

~~~
ZoFreX
You can pretty much guarantee that nothing in the core system for FreeBSD
calls Bash, because Bash isn't in the core system :)

------
propercoil
I don't know if I'm clear after the update. Is my bash version patched or is
it patched only for the first vulnerability?

GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)

------
panzi
Why does the output say 'foo' and not just foo? That looks suspicious.

------
carsonreinke
Anybody try this with an iPhone? Not sure if bash is even installed on it.

------
slavik81
What DHCP service is this and how do I tell if I'm using it?

------
Klasiaster
one more reason for networking done by network-manager or networkd (systemd)
instead of bash scripts

~~~
Sanddancer
NetworkManager's had vulnerabilities over the years (
[http://www.cvedetails.com/product/5634/Gnome-
Networkmanager....](http://www.cvedetails.com/product/5634/Gnome-
Networkmanager.html?vendor_id=283) ), as has systemd. Stating this as a reason
to switch is ridiculous. One can easily switch to a much more audited, secure
scripting environment, such as ksh, and still have all the power scripting
brings.

~~~
muyuu
Not saying I agree with GP, but "the power scripting brings" can be part of
the problem. Scripting is used as a means to execute arbitrary commands on a
single level privilege (that of the user hooking the scripts, very often root
or some high-privilege user) as opposed to a limited set of application-
specific functionality. This adds a whole level of complexity to the system,
which in security terms is typically the kind of thing that will give you
trouble.

~~~
azernik
Agreed. When in security classes we were taught to use e.g. execve() instead
of system(), it wasn't because shells were thought of as particularly
vulnerable. You just want to use a tool that has the minimum possible feature
set, so you can be sure that no one malicious will be able to trick you into
using even correctly-functioning features (e.g. through shell injection).

Sort of a special case of the principle of minimum privilege, when applied to
the feature set of your tools.

