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

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.

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.

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

The IT Pro guide to Windows 10 migration

Everything you need to know for a successful transition

Download now

Managing security risk and compliance in a challenging landscape

How key technology partners grow with your organisation

Download now

Software-defined storage for dummies

Control storage costs, eliminate storage bottlenecks and solve storage management challenges

Download now

6 best practices for escaping ransomware

A complete guide to tackling ransomware attacks

Download now
Advertisement

Most Popular

Visit/cloud/microsoft-azure/354230/microsoft-not-amazon-is-going-to-win-the-cloud-wars
Microsoft Azure

Microsoft, not Amazon, is going to win the cloud wars

30 Nov 2019
Visit/hardware/354237/five-signs-that-its-time-to-retire-it-kit
Sponsored

Five signs that it’s time to retire IT kit

29 Nov 2019
Visit/business/business-strategy/354252/huawei-takes-the-us-trade-sanctions-into-its-own-hands
Business strategy

Huawei takes the US trade sanctions into its own hands

3 Dec 2019
Visit/mobile/mobile-phones/354273/pablo-escobars-brother-launches-budget-foldable-phone
Mobile Phones

Pablo Escobar's brother launches budget foldable phone

4 Dec 2019