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

Already fixed in Debian...

[msauve]

Linky

Re:Already fixed in Debian...

[Anonymous Coward]

You probably tested with a command line that invokes bash explicitly. dash doesn't even have the feature that this exploit targets.

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.

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.

You are mistaken. No input processing needed

[raymorris]

> Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?

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

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:yum: Could not find update match for bash

[sosume]

sudo mv /bin/bash /bin/woosh

Detailed info from RedHat

[Beeftopia]

Example attacks are listed on Red Hat's security blog.