Warning: Linux security bashed by 22 year old remote code execution bug

A 22 year old vulnerability, yes you read that right, has been discovered which some security experts suggest could be bigger than Heartbleed. The bug, reported as 'CVE-2014-6271:remote code execution through bash' relates to how environment variables are processed: with trailing code in function definitions being executed independently of the variable name. This can be exploited remotely with code injected into environment variables across the network.

The GNU Bourne Again Shell (Bash) command interpreter is widely used, to put it mildly, and as such is being treated as a critical security risk to Unix and Linux systems. Which means it could actually impact upon routers, Macs running OS X, servers, websites etc etc. The Heartbleed reference comes courtesy not only of the potential widespread target surface, but also the length of time which this vulnerability has been present. Apparently the bug goes right back to version 1.13 of Bash, and hits all versions from then right up to (and including) version 4.2; which is, I repeat, a 22 year exploit window. On the plus side, it seems that the Dash alternative as employed by Ubuntu and Debian-derived systems is not impacted by the vulnerability.

You are advised to check if you are vulnerable by executing the following line in your shell:

env x='() { :;}; echo vulnerable' bash -c "echo start patching now"

If you see output of 'vulnerable - start patching now' then take heed and do just that. Or at least start doing that, because although Bash patches have been rushed out that doesn't mean you will be able to patch everything that requires patching. Does your wireless router shell out to ping or traceroute? Does your network use FTP or Telnet? Try patching those... This could be a major headache for admins and corporate security teams alike, scanning networks to try and blanket patch all internet-facing Linux machines.

[Gribouillis]

I don't dare execute your test line now.

[blud]

Test line should be safe, but yeah talk about a bad day for sysadmins.

[Gribouillis]

The test line is not safe. Here is my result

$ env x='() { :;}; echo vulnerable' bash -c "start patching now"
vulnerable
start: Tâche inconnue : patching

Tâche inconnue means unknown task. So bash echoed vulnerable and then tried to run the start command. On my system, /sbin/start is a symlink to the initctl command. Fortunately, initctl does not know the subcommand patching and it aborted.

Edit: After running the update manager, bash now says that it ignores the function definition attempt. It means that the bug has been corrected today for kubuntu 14.04.

[mike_2000_17]

Yeah, the test command should be:

$ env x='() { :;}; echo vulnerable' bash -c "if [ $? -ne 0 ] ; then echo \"start patching now\"; fi"

I tried it and it printed "vulnerable" for me, but I checked my updates and bash got updated to 4.3 and now the test command no longer shows it to be vulnerable. Yay!

[happygeek]

Arse. I missed an echo, apologies... Now fixed.

[rubberman]

Yes. Most distributions have already released the patches required to fix this. Now, people just have to update their systems to incorporate the fixes. This will be simpler than installing the heartbleed SSL bug patches with fewer possible side-effects (we hope).

[happygeek]

Some interesting comments coming in from the ITSec industry:

Jaime Blasco, AlienVault Labs Director.

We have been running a Honeypot since yesterday that basically emulates a system that is vulnerable. We found several machines trying to exploit the vulnerability. The majority of them are only probing to check if systems are vulnerable.

On the other hand we found two attacks that are actively exploiting the vulnerability and installing a piece of malware on the system.
These pieces of malware turn the systems into bots that connect to a C&C server where the attackers can send commands.

We have seen the main purpose of the bots is performing distributed denial of service attacks.

[happygeek]

This just hit my inbox from the ZScaler ThreatLabZ folk:

Within hours of the public disclosure of this vulnerability, the Zscaler ThreatLabZ research team started seeing incidents of attacks targeting this vulnerability in the wild to download additional malware. It appears that Nginx and Apache web servers configured to use mod_cgi are two potentially vulnerable services that are actively being targeted in the wild. The server involved was found to be compromised and hosting ELF binaries which belong to the same Linux Backdoor Trojan family with DDoS capabilities. Zscaler believe that the vulnerable Apache servers were resulting in the download of an ELF binary named "apache" whereas vulnerable Nginx servers were getting the ELF binary named "nginx". The only difference Zscaler saw in these two binaries was the hardcoded Command and Control server information. Upon successful exploitation of CVE-2014-6271 vulnerability, the attacker is able to download and install the malicious ELF binary on the target Linux system. The malware connects to a predetermined Command and Control (C2) server on a specific port and awaits further instructions from the attacker

[Slavi]

Thanks 4 sharing

[JasonHippy]

Here's some great advice for Linux sys-admins who want to detect and block attempts by would-be attackers who are testing your servers for this bug, or who have already taken advantage of it:
http://www.linuxbrigade.com/bash-shellshock-bug-find-youve-tested/

Even if your server has already been patched, it probably makes sense to block anybody who is testing for the presence of the bug as they are obviously up to no good!

[blud]

If you patched on Thursday or Friday, the patch wasn't complete. CVE-2014-7169 covers the new exploit.

Test code
[code]env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo[/code]

[happygeek]

More news from the security research labs:

FireEye has discovered that cyber attackers have already mobilised to use BASH Shellshock bug and suspect that they may be conducting initial dry runs in preparation for a real, potentially larger scale, attack. Some of the suspicious activity appears to be originating from Russia, although there has been frenzied activity from all over the world. It’s believed that it’s only a matter of time before attackers exploit the vulnerability to redirect users to malicious hosts, which can result in further compromise. So far, the Common Gateway Interface vector (an interface between a web server and executables that produce dynamic content) has received the bulk of the focus from attackers, however, the reach of the BASH Shellshock bug doesn’t stop at web servers. Any application that relies on user-controlled data to set OS-level environment variables and then invokes the shell from that same context can trigger the vulnerability. In other words, web applications relying on a specific type of user input can be manipulated to make clients (i.e., consumers) vulnerable to attack.

[blud]

Updated code to test for all of the current CVE's

#!/bin/bash

warn() {
if [ "$scary" == "1" ]; then
echo -e "\033[91mVulnerable to $1\033[39m"
else
echo -e "\033[93mFound non-exploitable $1\033[39m"
fi
}

good() {
echo -e "\033[92mNot vulnerable to $1\033[39m"
}

[ -n "$1" ] && bash=$(which $1) || bash=$(which bash)
echo -e "\033[95mTesting $bash ..."
echo $($bash --version | head -n 1)
echo -e "\033[39m"
#r=`a="() { echo x;}" $bash -c a 2>/dev/null`
if [ -n "$(env 'a'="() { echo x;}" $bash -c a 2>/dev/null)" ]; then
echo -e "\033[91mVariable function parser active, maybe vulnerable to unknown parser bugs\033[39m"
scary=1
elif [ -n "$(env 'BASH_FUNC_a%%'="() { echo x;}" $bash -c a 2>/dev/null)" ]; then
echo -e "\033[92mVariable function parser pre/suffixed [%%, upstream], bugs not exploitable\033[39m"
scary=0
elif [ -n "$(env 'BASH_FUNC_a()'="() { echo x;}" $bash -c a 2>/dev/null)" ]; then
echo -e "\033[92mVariable function parser pre/suffixed [(), redhat], bugs not exploitable\033[39m"
scary=0
elif [ -n "$(env 'BASH_FUNC_<a>%%'="() { echo x;}" $bash -c a 2>/dev/null)" ]; then
echo -e "\033[92mVariable function parser pre/suffixed [<..>%%, apple], bugs not exploitable\033[39m"
scary=0
else
echo -e "\033[92mVariable function parser inactive, bugs not explitable\033[39m"
scary=0
fi

r=`env x="() { :; }; echo x" $bash -c "" 2>/dev/null`

if [ -n "$r" ]; then
warn "CVE-2014-6271 (original shellshock)"
else
good "CVE-2014-6271 (original shellshock)"
fi

cd /tmp;rm echo 2>/dev/null
env x='() { function a a>\' $bash -c echo 2>/dev/null > /dev/null

if [ -e echo ]; then
warn "CVE-2014-7169 (taviso bug)"
else
good "CVE-2014-7169 (taviso bug)"
fi

$($bash -c "true $(printf '<<EOF %.0s' {1..80})" 2>/tmp/bashcheck.tmp)
ret=$?
grep -q AddressSanitizer /tmp/bashcheck.tmp

if [ $? == 0 ] || [ $ret == 139 ]; then
warn "CVE-2014-7186 (redir_stack bug)"
else
good "CVE-2014-7186 (redir_stack bug)"
fi

$bash -c "`for i in {1..200}; do echo -n "for x$i in; do :;"; done; for i in {1..200}; do echo -n "done;";done`" 2>/dev/null

if [ $? != 0 ]; then
warn "CVE-2014-7187 (nested loops off by one)"
else
echo -e "\033[96mTest for CVE-2014-7187 not reliable without address sanitizer\033[39m"
fi

$($bash -c "f(){ x(){ _;};x(){ _;}<<a;}" 2>/dev/null)

if [ $? != 0 ]; then
warn "CVE-2014-6277 (lcamtuf bug #1)"
else
good "CVE-2014-6277 (lcamtuf bug #1)"
fi

if [ -n "$(env x='() { _;}>_[$($())] { echo x;}' $bash -c : 2>/dev/null)" ]; then
warn "CVE-2014-6278 (lcamtuf bug #2)"
elif [ -n "$(env BASH_FUNC_x%%='() { _;}>_[$($())] { echo x;}' $bash -c : 2>/dev/null)" ]; then
warn "CVE-2014-6278 (lcamtuf bug #2)"
elif [ -n "$(env 'BASH_FUNC_x()'='() { _;}>_[$($())] { echo x;}' $bash -c : 2>/dev/null)" ]; then
warn "CVE-2014-6278 (lcamtuf bug #2)"
else
good "CVE-2014-6278 (lcamtuf bug #2)"
fi

[Coloradojaguar]

I was reading this week that another patch may be required. Seems it may be deeper than first thought. Anyone has new information on this?

[happygeek]

There are a whole host of sub-issues (for want of a better word) that have been discovered, and so you should ensure you have the latest patch as applicable.

[happygeek]

Useful information about the evolution of Shellshock attack payloads to be found here:

http://research.zscaler.com/2014/10/bashed-evolution-of-shellshock-attack.html

[jonmaekle]

Test line should be safe

[Djmann1013]

Even non-server distributions are effected (Ubuntu 14.04 LTS):

https://i.imgbomb.com/PBfXu.png