Remember Heartbleed a while back this year and all the hype that was made over it? Well this new vulnerability, dubbed "Shellshock" may just be even worse. Stephane Chazelas, a security research from Akamai, uncovered a massive flaw in the Unix Bash shell, leaving Linux machines, OS X machines, routers, older IoT devices, and more open to devastating attacks.

Bash is a Unix shell written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell (sh). Most Unix-based operating systems today use bash as the default shell including Linux and Mac OS X, and additionally bash has been ported to many other systems including Windows (with software such as Cygwin) and Android. The fact that bash is so widely used means that this is an extremely significant vulnerability.

So what exactly is this thing anyway, and how do you know if you're at risk? Let's examine this vulnerability in a little detail and find out why it's so dangerous, and we can find out how to test for it and patch your system.

What is Shellshock?

Put simply, this new Shellshock vulnerability potentially allows attackers to execute arbitrary shell commands on your machine.

But the even scarier thing about this vulnerability is that it's extremely old, meaning that it could have potentially been exploited for years now (and may have even been exploited without having been revealed). Since the vulnerability is so old, it's quite widespread, which means that it will likely still be seen unpatched in many systems for quite some time.

However, as bad as this vulnerability may be, the average person is less at risk than with Heartbleed. According to Jen Ellis of security firm Rapid7:

The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue. In order to exploit this flaw, an attacker would need the ability to send a malicious environment variable to a program interacting with the network and this program would have to be implemented in Bash, or spawn a sub-command using Bash.

However, for those whose systems are remotely exploitable, it's dangerously easy. Imagine an HTTP request like this:

target =
port = 80
banners = true
http-user-agent = shellshock-scan
http-header = Cookie:() { :; }; ping -c 3
http-header = Host:() { :; }; ping -c 3
http-header = Referer:() { :; }; ping -c 3

When this request is passed to a range of vulnerable IP addresses it results in the requested command (i.e. ping) being executed. You can easily test this on your own device using software such as Wireshark. A ping is pretty harmless, but imagine what kind of devastating options this leaves open.

Am I Vulnerable?

Checking if your system is vulnerable to Shellshock is actually pretty easy. Just open a shell and execute this:

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

If you see this it means you are vulnerable!

this is a test

If your system is not vulnerable, you'll see something like this:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

How Do I Fix It?

Fortunately, this vulnerability is pretty easy to patch. Here are some steps to take for a few various distros:

Debian 6:
If you're on Debian 6, add the necessary sources to your sources.list:

# make sure you are on debian 6
cat /etc/issue
# add the LTS sec repo
echo "#LTS security" >> /etc/apt/sources.list
echo "deb squeeze-lts main contrib non-free" >> /etc/apt/sources.list
echo "deb-src squeeze-lts main contrib non-free" >> /etc/apt/sources.list

Then continue on to the Debian 7 instructions to install the updates.

Debian 7:

# update and install patched bash
apt-get update
apt-get install bash

Centos 6/7:

yum -y install bash
yum -y update

Red Hat:

#The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function #definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI #applications
#Request Header values:
SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
#GET/POST names:
SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
#GET/POST values:
SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
#File names for uploads:
SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"
#These may result in false positives but it's unlikely, and they can log them and keep an eye on it. You may also want to avoid #logging as this could result in a significant amount of log files.

After installing the updates, be sure to test your system again to ensure that the vulnerability is indeed removed.