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

happygeek

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.

880 Views
About the Author

A freelance technology journalist for 30 years, I have been a Contributing Editor at PC Pro (one of the best selling computer magazines in the UK) for most of them. As well as currently contributing to Forbes.com, The Times and Sunday Times via Raconteur Special Reports, SC Magazine UK, Digital Health, IT Pro and Infosecurity Magazine, I am also something of a prolific author. My last book, Being Virtual: Who You Really are Online, which was published in 2008 as part of the Science Museum TechKnow Series by John Wiley & Sons. I am also the only three times winner (2006, 2008, 2010) of the BT Information Security Journalist of the Year title, and was humbled to be presented with the ‘Enigma Award’ for a ‘lifetime contribution to information security journalism’ in 2011 despite my life being far from over...

Gribouillis 1,391 Programming Explorer Team Colleague

I don't dare execute your test line now.

blud 82 Linux Reject Moderator

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

Gribouillis 1,391 Programming Explorer Team Colleague

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 2,669 21st Century Viking Team Colleague Featured Poster

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 2,411 Most Valuable Poster Administrator Featured Poster

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

rubberman 1,355 Nearly a Posting Virtuoso Featured Poster

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 2,411 Most Valuable Poster Administrator Featured Poster

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 2,411 Most Valuable Poster Administrator Featured Poster

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 94 Master Poster Featured Poster

Thanks 4 sharing

JasonHippy 724 Practically a Master Poster

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 82 Linux Reject Moderator

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 2,411 Most Valuable Poster Administrator Featured Poster

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 82 Linux Reject Moderator

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 0 Light Poster

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 2,411 Most Valuable Poster Administrator Featured Poster

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 2,411 Most Valuable Poster Administrator Featured Poster

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 0 Newbie Poster

Test line should be safe

Djmann1013 commented: I wouldn't be so sure. +0
Djmann1013 0 Mr. Parker

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

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

Be a part of the DaniWeb community

We're a friendly, industry-focused community of 1.19 million developers, IT pros, digital marketers, and technology enthusiasts learning and sharing knowledge.