Shellshock – bash bug – CVE-2014-6271


The information security field has been lit up over the last few hours discussing “Shellshock” the next Heartbleed type vulnerability (in terms of severity), the jury is still out as to whether this is worse but it’s certainly looking to be at least as bad as Heartbleed at this stage in proceedings.

In the Wild

Perspective Risk has already identified scan attempts looking for the vulnerability, albeit from a security researcher conducting an assessment of the impact of the flaw:

[shell] – – [25/Sep/2014:01:15:26 -0400] "GET / HTTP/1.0" 200 168900 "() { :; }; ping -c 11" "shellshock-scan (<a href=""></a>)"[/shell]

The Details

The vulnerability itself, is relatively complex, simply calling bash is not the issue, the vulnerability arises when environment variables are passed to bash.  All of the talk as the moment is in regard to web attack vectors and in particular CGI scripts which do pass environment variables to bash, but as the nature of the issue becomes better understood, more intelligent and more diverse attacks will certainly start to appear.

The following Proof of Concept String can be used to determine whether your systems are vulnerable (or not):

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

Vulnerable system example:

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


this is a test[/shell]

The patch used to fix this flaw, ensures that no code is allowed after the end of a bash function. So if you run the above example with the patched version of bash, you should get an output similar to:


[shell]bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test[/shell]

Exploiting the Bug

An initial Metasploit Module has already been released for this issue and only requires a vulnerable CGI script to perform a compromise of the remote system:


Test Yours

Vulnerability checks have already sprung up if you want to test your web server and scripts for this issue:

Current Remediation Advice

There are discussions about a possible attack workaround for the new patch, but as it stands the best advice at the moment is to apply the appropriate vendor patch; as patched systems are apparently more complex to exploit.

The more paranoid among us may wish to take extra measures whilst the vendor responses to this issue mature:

iptables rule to block the exploit (untested):

[shell]iptables -I INPUT -p tcp –dport 80 -m string –algo bm –string ‘() { :;};’ -j DROP[/shell]