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

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

[Jizzbug]

https://marc.info/?l=oss-security&m=141157106132018&w=2

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.

So now it's the year of the Linux desktop

[Anonymous Coward]

Because we've finally become popular enough to warrant script kiddies finding holes in our toys!
Captcha: Outcry

Re:So now it's the year of the Linux desktop

[flyingfsck]

Oh my, that's torn it. Now I'll have to switch to Minix.

Re:So now it's the year of the Linux desktop

[CRCulver]

You do realize that bash is (nowadays) installed in damned near every *nix out there (though I think HPUX is still holding out.)

Debian and a few other distros have long since switched to Dash as their /bin/sh. Openwrt uses ash (installing bash would require intentional effort), and I assume that many *nix devices with the Busybox environment in lieu of the traditional GNU toolset also eschew bash. Sure, bash is still common out there, but thankfully not as prominent as a decade ago, and even when present it might not be exposed to an attacking surface.

Missing in windows?

[Anonymous Coward]

I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?

Thanks.

Re:Missing in windows?

[flyingfsck]

It's because there is no start menu in Windows anymore, you dum dum...

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...

Re:Missing in windows?

[clovis]

I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?

Thanks.

You seem to have asked a question about removing the Start Menu.
Upgrade to Windows 8, but do not do the Win8.1 upgrade.
Thank you for using our products in the future.

Re:Missing in windows?

[_xeno_]

I just updated Cygwin to the latest, and yes, it's still vulnerable. (At least its bash-4.1.10-4 is, I suppose it's possible that the mirror I'm using is out of date.)

Re:Missing in windows?

[Anonymous Coward]

Um, that's not a shell that I know of. Citation needed?

CentOS 6.5 already has fixed package available

[astro]

sudo yum update bash

Thank you for the quick warning.

Already fixed in Debian...

[msauve]

Linky

Thanks god

[Anonymous Coward]

Thanks god I am using windows.

Re:Thanks god

[msauve]

Your god makes you use Windows? You have a vengeful god.

Test string here:

[B5_geek]

This is the test to see if you are vulnerable:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Re:Test string here:

[B5_geek]

SSH into your host.
from the bash prompt just paste the above string.

i.e.
user@host $env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

--------------------
If you see:
vulnerable
this is a test
Then you are vulnerable and need to update your system.

If all you see is:
this is a test

Then you are ok.

Re:Test string here:

[chihowa]

The (ancient) version of bash that ships with OS X appears vulnerable. Luckily, as a remote exploit, only authenticated ssh sessions and cgi scripts etc expose it, so most single user workstations (of all OSs) should be safe.

If this is a bash exploit, and not a Linux exploit, why all of the focus on Linux in the article? I use bash on many different OSs.

Re:Test string here:

[OzPeter]

I just tried it on 2 different version s of OSX: 10.9.4 and 10.7.5 and confirm that they print out the "vulnerable" message

Re:Test string here:

[multiplexo]

Most sshd daemons aren't configured to accept just any environment variables, they limit exposure with an AcceptEnv directive in the sshd configuration file (/etc/ssh/sshd_config on most Linux versions. This means that

env x='() { :;}; echo vulnerable' ssh some_user@some_server

probably won't work on most systems but

env LC_FRED='() { :;}; echo vulnerable ssh some_user@some_server'

will if the server is configured to accept the LC_* environment variables with the AcceptEnv directive in sshd_config.

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:Dangerous

[flyingfsck]

Awww, come on, don't bash Bash when it is down...

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.

Not arbitrary variables - QUERY_STRING

[raymorris]

> 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.

The contents of the CGI script don't matter. The exploit occurs before the script runs. It happens as bash is setting up the environment in which the script will be run.

Suppose you have pwd.cgi, which prints the name of the current directory:

#!/bin/sh
echo -e "Content-type: text/plain\n\n"
pwd

Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.

Re:Not arbitrary variables - QUERY_STRING

[menkhaura]

Setup a local cgi script on your Linux machine. Telnet into its port 80. Assuming your cgi script is at /cgi-bin/test.sh, type the following in the telnet prompt:

GET /cgi-bin/um.pl HTTP/1.1
Host: localhost
Custom: () { :; }; while read -r l; do echo $l; done

Press ENTER twice after the last header.

If you don't use a shell builtin, the shell ends with a segfault and Apache shows an error, but the command is executed server-side. Scary.

Re:Dangerous

[jhantin]

ksh

Pfffft. I should have expected Korny jokes. (Ba-dum-csh.)

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.

Re:Dangerous

[Culture20]

Bash has always felt a bit dangerous...

POUND! BANG! SLASH! bin SLASH! BASH!
#!/bin/bash