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.

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.

Advertisement
Advertisement - Article continues below
Advertisement - Article continues below

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.

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.

Advertisement - Article continues below

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.

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

Advertisement
Advertisement - Article continues below

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.

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.

Advertisement - Article continues below

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

What you need to know about migrating to SAP S/4HANA

Factors to assess how and when to begin migration

Download now

Your enterprise cloud solutions guide

Infrastructure designed to meet your company's IT needs for next-generation cloud applications

Download now

Testing for compliance just became easier

How you can use technology to ensure compliance in your organisation

Download now

Best practices for implementing security awareness training

How to develop a security awareness programme that will actually change behaviour

Download now
Advertisement

Most Popular

Visit/policy-legislation/data-governance/354496/brexit-security-talks-under-threat-after-uk-accused-of
data governance

Brexit security talks under threat after UK accused of illegally copying Schengen data

10 Jan 2020
Visit/security/cyber-security/354468/if-not-passwords-then-what
cyber security

If not passwords then what?

8 Jan 2020
Visit/policy-legislation/31772/gdpr-and-brexit-how-will-one-affect-the-other
Policy & legislation

GDPR and Brexit: How will one affect the other?

9 Jan 2020
Visit/web-browser/30394/what-is-http-error-503-and-how-do-you-fix-it
web browser

What is HTTP error 503 and how do you fix it?

7 Jan 2020