Remote Exploit Vulnerability Found In Bash

kdryer39 sends this news from CSO: A remotely exploitable vulnerability has been discovered by Stephane Chazelas in bash on Linux, and it is unpleasant. The vulnerability has the CVE identifier CVE-2014-6271. This affects Debian as well as other Linux distributions. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables. Also through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

Comments

Only CGI scripts affected?

[Anonymous Coward]

So, if I undestand correctly, this affects shell scripts used for CGI; do people actually do that on what scale?

Only person I know who does this is a CS teacher in my college, onhis homepage which he has had since early 90s, are there actually commercial installations which do this, some major product with large install base ("asking this for my son")?

Re:Only CGI scripts affected?

[TheCarp]

Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.

That said, you know someone does this. Hell, I have had to deal with web applications written mostly in shell and did much of their processing in shell.... the only thing that really topped it for idiocy was when I dove into some perl4 code for a password change form and found this gem:

$password = $q->param('password');
if "`grep $password /usr/dict/words`" != "" {
}

No taint checking, nothing, just shell out with whatever someone put in the form. I loaded it up and added a "; touch /tmp/foo" on the end and verified there was no protection, then I found 4 more similar errors and figured that since security issues were not even why I opened the code to read it....I re-wrote it from scratch.

Re:Full Disclosure can be found on oss-security...

[lgw]

This is exceedingly nasty.

The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function
definition. ...

The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.

This is a weapons-grade exploit IMO, the sort of thing the NSA keeps hidden for when it's really needed. I'm almost surprised it wasn't suppressed.

Hmm, I wonder how many phones are valuable.

Really? Using bash for CGI?

[Anonymous Coward]

All the systems I've done security pen tests against that were using bash for CGI were so easy to hack via other means it wasn't funny. And of course that web server CGI was running as root so root shell and done.

Stop using Bash for CGI unless you want to get pwned. Similar theme with 90% of the Perl CGI I run into.

Re:Missing in windows?

[just_another_sean]

Seriously though is cygwin's bash vulnerable?

Looks like it is to me, haven't had a chance to check for an update yet though...

so a remote fork bomb is possible?

[Killer Instinct]

VAR=() { ignored; }; : :(){ :|:& };:

Re:so a remote fork bomb is possible?

[multiplexo]

Yes, run this:

env LC_BOMB='() { :;}; :(){ :|:& };:' ssh some_user@some_system

And if some_user is using bash and the ssh daemon on the system is configured with AcceptEnv LC_*, which most of them are, you'll end up with an awesome remote fork bomb.

Worse than you think.

[slimjim8094]

Almost *ANY* CGI is vulnerable, because the way CGI works is by environment variables. And the attacker can control them. You don't have to be doing anything stupid or wrong to be affected. It looks like other ways of executing web applications (e.g., mod_php) are safe - to the extent that they don't use a popen or a system() or something, which is a pretty common thing to do.

Your DHCP client (on a Linux) machine passes data to its hooks via environment variables. These can be set by the attacker. Even better, it's running as root. Boom, connect to a rogue AP and get rooted while receiving an address assignment.

You probably do Git commits via a (locked-down) SSH login. That's compromised.

Shells are everywhere. Again, this doesn't require your application to have screwed up. This is a flaw in how environment variables are parsed and set, which is something that was presumed safe, so nobody thought about it. Bad bad bad bad. Not Heartbleed bad, but close.