Shellshocked by the sysadmin weekend from hell

Davey Winder explains why patience is a virtue when it comes to patching the Bash bug vulnerability

I am sorry to say that I suffer from migraines, but sysadmins found themselves with an even bigger headache over the weekend, courtesy of the 22-year-old Bash bug, or Shellshock vulnerability.

The remote code execution through Bash does what it says on the tin by allowing trailing code in function definitions to be executed independently of the variable name and exploited remotely across the network.

Advertisement - Article continues below

In one sense, this is a good thing. Sometimes people need to be "shellshocked" into a state of reality, with those who are so comfortable in their denial of risk prime becoming candidates to be targeted.

This means you, if you are a dyed-in-the-wool Linux or Mac evangelist. Sure, Windows gets the brown and smelly end of the proverbial insecurity stick and there, but that doesn't mean bad things cannot and do not happen elsewhere.

The GNU Bourne Again Shell (Bash) command interpreter is not some backwater bit of business, it's right up there with Windows in terms of popular usage, making it both a big target and a ripe risk. This has been, without doubt, a critical security risk to Linux and Unix systems, to Macs running OS X, routers, servers, and websites.

The fact that the threat window has been open for 22 years, back to version 1.13 of Bash in fact, only makes it all the more serious.

Advertisement - Article continues below
Advertisement - Article continues below

As soon as I became aware of the situation, I started advising people check their vulnerability status by executing the following line in their shell:

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

If an output of 'vulnerable - start patching now' was returned, then it was vulnerable and needed patching. If a patch was available, of course.

The Microsoft bashers immediately jumped up and down demanding patches in double-quick time, unlike the slow 'wait at least a month' process for Windows updates.

Let's not throw the historic, slow security reaction times of Apple into the mix here, but the rude hand gestures of the evangelists can be tempered by two things. Number one being that not everything can be patched quite so easily as people would like. Blanket patching of internet-facing Linux machines following network scans and audits has been headache number one for sysadmins, and shows little sign of easing up.

Advertisement - Article continues below

The second thing to bear in mind is those who were on the ball and patched early into the Bash crisis, last Thursday or Friday, for example, will have done so using an incomplete patch. Yep, Red Hat announced the patch for CVE-2014-6271 actually still allowed "environment variables containing arbitrary commands" to be "executed on vulnerable systems under certain conditions."

This updated Bash vulnerability gets a new alert tag of CVE-2014-7169. If you want to see if your patch has actually patched properly you will need to run some more test code, namely:

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

All of this scanning of servers, routers and anything else using the Bash shell, followed by patching and quite possibly repatching, has had to be done against a backdrop of sand running through an upturned timer. Long shifts are nothing new to the average sysadmin or security team, but these last few days have been hell on earth.

Advertisement - Article continues below

Proof of concept code is out there, a metasploit module is already being distributed, and honeypots specifically aimed at the issue have been probed more than a drunk redneck walking through the woods. Active attacks are happening, with malware being installed that turn vulnerable systems into bots (according to research by security research labs) to be used for DDoS purposes.

The good news, such as it is, would seem to be that most experts agree that most systems with Bash installed will not actually be remotely exploitable in a real-world scenario. The bad news, and yet another headache, is that while it's really easy to test for the vulnerability, it's very difficult indeed (read time consuming and costly, rather than totally impossible) to test whether that vulnerability is truly exploitable across the network.

So the truth of the matter is there isn't enough data available to us yet to determine the real scope of Shellshock as an exploitable vulnerability. That data will emerge in time, and only then will the headaches start to recede. Unless that data shows that the bad guys are finding ways to reach those difficult to patch systems.

Featured Resources

Preparing for long-term remote working after COVID-19

Learn how to safely and securely enable your remote workforce

Download now

Cloud vs on-premise storage: What’s right for you?

Key considerations driving document storage decisions for businesses

Download now

Staying ahead of the game in the world of data

Create successful marketing campaigns by understanding your customers better

Download now

Transforming productivity

Solutions that facilitate work at full speed

Download now



Researchers detail Tetrade family of Brazilian banking trojans

16 Jul 2020
ethical hacking

Mobile banking apps are exposing user data to attackers

26 Jun 2020

Most malware came through HTTPS connections in Q1 2020

25 Jun 2020

Phishing attacks target unsuspecting Wells Fargo customers

24 Jun 2020

Most Popular

Careers & training

IBM job ad calls for 12-years of experience with six-year-old Kubernetes

13 Jul 2020

The rise of containers

9 Jul 2020
Business operations

Nvidia overtakes Intel as most valuable US chipmaker

9 Jul 2020