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...)
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.
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.
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.
You say dhclient should take into account all possible contexts before passing data to bash, but it's not easy to know what data shells will parse as code and what they won't[1]. If we have to sanitise data before passing it to shells then the only sane conclusion is to never pass untrusted data to shell scripts. I certainly don't trust myself to know the full range of features in all shells that might suddenly turn a plain text string into executed code. I can't think of any other people that I would trust to know that either.
Is that really what you are advocating here? Don't ever use shell scripts with untrusted data? That has been my philosophy for a long time, but up till now that position has been viewed as extreme by most people I've shared it with.
The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh
It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely.
So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (and other places where "/bin/sh --version" indicates that it's bash) first.
Yes, potentially - if at any point during the execution of a program (or its descendents) a bash script gets called with an untrusted environment variable value from a remote source. The difference between a system with bash as /bin/sh and a system with dash as /bin/sh is that the bash system is implicitly executing bash all the time, whereas the dash system requires an explicitly-bash script to be executed. So the dash system has many fewer windows of opportunity for an exploit, but they could still be there.
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.
Woah. This is getting blown a little out of proportion now. It's a bad bug, but we don't need a bunch of misinformation about it:
1. The released patch (and subsequent update for many distributions) fixed the only currently-known remotely exploitable version of the bug. The cases found afterward are a different bug, and so far there's no publicly known way to remotely exploit it. These other bugs were published to demonstrate that there are deeper flaws in bash's parsing of environment variables. If you have updated bash with the most recent fix, the odds are in your favor that you're going to be just fine.
2. "Routers, web cameras, SIP gateways, NAS’s" & etc. all need to be running a variant of bash to be exploitable. dash doesn't have this problem. ksh, csh, other shells don't have this problem. ash, used by BusyBox, doesn't have this problem. BSD-based systems don't have this problem (except in rare circumstances).
3. DHCP exploitation requires that you have network-start scripts that are run by bash on your system, and you're getting DHCP from a compromised host.
4. Yes, ssh hosts are vulnerable -- if you already have ssh access to those hosts and your shell is bash. This bug doesn't give most users a level of access that they don't already have. But, it can mean that if a user is restricted to specific commands for sudo without being prompted for a password, then they can run arbitrary sudo commands, which isn't very nice.
5. And yeah, mass-scanning started late last night and the first examples of malware using this as a vector are being seen. As scanning techniques improve -- currently they're pretty rudimentary -- more and more hosts will get compromised.
If you have bash installed, but it isn't the system bash (/bin/sh), and none of your scripts explicitly call bash or have a bash shebang, then you aren't vulnerable. However, if bash is your /bin/sh, then even a script that appears to have nothing to do with bash but happens to call something like system() will invoke bash.
Yes. Just about anything that winds up running bash with an unsanitized environment that an attacker could influence is potentially vulnerable. The GP poster has no idea what they are talking about.
bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache).
Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options.
The attacker also has to have a local privilege escalation vulnerability to exploit as well, or they're trapped as the CUPS user once they do bust in.
I don't think that the level of panic I have seen on other Hacker News threads and elsewhere on the Internet is warranted. Comparing this to Heartbleed is pretty absurd; TLS vs bash CGI is no contest in terms of deployment size.
I'm mainly concerned with public-facing, large scale web services, and in that area:
1. CGI in general and bash CGI in particular are basically unheard of.
2. system() in other scripting languages might be used, BUT to be vulnerable you have to pass through user-supplied data as environment variables without sanitizing. This was always an exploit waiting to happen.
3. ssh accounts with a command forced in authorized_keys are potentially problematic, but this would only be from users who have some relationship to your service in the first place. Personally I think a restricted shell (rsh or git-shell or whatever) is a more common option, simply because who knows what bash might get up to.
4. DHCP client scripts on Linux is an interesting exploit path, and might be a problem for laptops on shared wifi, but for the majority of Linux servers there is no attack vector. They live on controlled networks where rogue DHCP servers can't be operated.
So yes, patch the vulnerability and audit your systems and code. Also keep the response proportional to the vulnerability, this one needs a lot of other things to fall into place to be exploited.
The point here is that Bash was not designed to receive untrusted user data in environment variables. On the other hand, Apache/dhclient was designed to receive untrusted data, but then handed that over to someone which did not expect untrusted data without validation.
In other words, if Apache/dhclient wants to put things into environment variables, it absolutely should make sure to do this properly and indeed to take into account all possible contexts.
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.
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...)
reply