6

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.

Edited by happygeek

As Editorial Director and Managing Analyst with IT Security Thing I am putting more than two decades of consulting experience into providing opinionated insight regarding the security threat landscape for IT security professionals. As an Editorial Fellow with Dennis Publishing, I bring more than two decades of writing experience across the technology industry into publications such as Alphr, IT Pro and (in good old fashioned print) PC Pro. I also write for SC Magazine UK and Infosecurity, as well as The Times and Sunday Times newspapers. Along the way I have been honoured with a Technology Journalist of the Year award, and three Information Security Journalist of the Year awards. Most humbling, though, was the Enigma Award for 'lifetime contribution to IT security journalism' bestowed on me in 2011.

10
Contributors
18
Replies
200
Views
3 Years
Discussion Span
Last Post by Djmann1013
1

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.

Edited by Gribouillis

1

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!

0

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

Edited by rubberman

1

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.

2

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

2

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]

2

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.

3

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

Edited by blud: Updating script

0

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?

0

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.

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.