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.
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:
Get the ITPro. daily newsletter
Receive our latest news, industry updates, featured resources and more. Sign up today to receive our FREE report on AI cyber crime & security - newly updated for 2024.
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
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.
Davey is a three-decade veteran technology journalist specialising in cybersecurity and privacy matters and has been a Contributing Editor at PC Pro magazine since the first issue was published in 1994. He's also a Senior Contributor at Forbes, and co-founder of the Forbes Straight Talking Cyber video project that won the ‘Most Educational Content’ category at the 2021 European Cybersecurity Blogger Awards.
Davey has also picked up many other awards over the years, including the Security Serious ‘Cyber Writer of the Year’ title in 2020. As well as being the only three-time winner of the BT Security Journalist of the Year award (2006, 2008, 2010) Davey was also named BT Technology Journalist of the Year in 1996 for a forward-looking feature in PC Pro Magazine called ‘Threats to the Internet.’ In 2011 he was honoured with the Enigma Award for a lifetime contribution to IT security journalism which, thankfully, didn’t end his ongoing contributions - or his life for that matter.
You can follow Davey on Twitter @happygeek, or email him at davey@happygeek.com.