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.
You missed one of the big ones, DHCP. dhclient calls dhclient-script with attacker controlled environment variables, and on several Linux distros I checked, dhclient-script explicitly uses Bash, so even Debian and Ubuntu, which use dash as sh, are vulnerable.
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 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.
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.
The one major one I found was the DHCP vulnerability; if you use ifupdown and configure and interface via DHCP, that uses dhclient, which invokes dhclient-script with attacker controlled variables. dhclient-script is explicitly written in bash, so is vulnerable.
I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable.
Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before.
There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable.
No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users.
This is NOT remotely exploitable.
It's an ad campaign for "security researchers" people.
Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable.
Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before.
There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable.
No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users.
This is NOT remotely exploitable.
It's an ad campaign for "security researchers" people.
Oh stop this stupidity already. If you are not running a Web server that spawns bash when serving an HTTP request, then you are NOT vulnerable.
Are you running a Web server that uses CGI scripts written in shell or plain C that uses system() call? If you do, you have had other problems long before.
There are some grumblings about DHCP _client_ setups on Linux passing parameters via environment variables to shell scripts executed by bash, but I am yet to see this. This would be a problem, but probably easily fixable.
No need to panic or even patch anything (as always). If you running servers on your machine and allow inbound connections you should know exactly what those servers are and what they execute on behalf of external users.
This is NOT remotely exploitable.
It's an ad campaign for "security researchers" people.
Have you got a source for OS X DHCP being vulnerable? OS X has a copy of bash at /bin/sh so it's pretty vulnerable if you can find a way to remotely set environment variables and call system().
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:
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.
The CGI and SSH attack vectors are getting a lot of attention because they are so trivially exploitable. But as someone (I believe tptacek) put it in another thread, this bug has one of the biggest potential attack surfaces in history. Anything that sets any environment variable to an untrusted value and then invokes bash is vulnerable. For example, on some systems, simply connecting to an attacker-controlled network is enough to cause code execution through the DHCP client.
If you choose not to upgrade bash, you are trusting that none of the code on your system uses bash in this way. It's extremely unlikely that the vectors that have been publicized so far are the only major ones.
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...)
> It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash.
The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).
Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
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.
reply