Sometimes security makes you feel tired. Less than six months after Heartbleed, the security industry now has had the potentially even more serious Bash or ‘Shellshock’ CVE-2014-6271 flaw dumped in its lap. Exactly how serious is open to some interpretation but everyone seems to agree on one thing – this one won’t be easy to fix.
Apparently first documented last week by researcher Stephane Chazelas (who has a relationship with Akamai but does not work for them), described simply the flaw allows a would-be attacker to take remote control of mainly older systems running the Bash command shell that has been embedded inside Unix and Linux for more than two decades.
The seriousness of the issue can be judged from the NVD’s impact and exploitability subscore of ‘10’, which is as bad as a vulnerability can possibly get. But how bad is bad on this scale? It is becoming incredibly hard even for experts to tell.
In theory a flaw in Bash is a bad thing because it’s already often used for remote access to systems via (note: authenticated) SSH or telnet and so its potential for attackers needs no spelling out. And because it offers scripting, the Linux world has embedded Bash as a sort of glue to make lots of normally obscure but important things happen, for example Apache servers executing Bash CGI scripts. Industrial control systems, some routers and even Internet of Things devices are probably full of it and, shock horror, it’s even inside Mac OS X.
But the conditions under which this flaw could cause problems remain fairly limited if hard to quantify, as a number of expert blogs have made clear.
“The conclusion we reached is that some factors are worse, but the overall picture is less dire [than Heartbleed]. This vulnerability enables attackers to not just steal confidential information as with Heartbleed, but also to take over the device or system and execute code remotely,” said Rapid7’s director of communications, Jen Ellis.
The bigger problem in a nutshell is that huge numbers of systems embed Bash so mitigating the effects is going to be incredibly difficult. The exact vulnerability of Bash within a particular setup will also depend on what it is being used to do and passing any attack through another application first. That reduces the scope - this is no dial-up exploit.
A bigger nasty is that the issue has been around for a long long time, which increases the number of vulnerable systems far beyond anything estimated for Heartbleed. As with so many of security flaws, it is the long tail that is hard to reach.
Patches are already available from Red Hat and Fedora and others, but the sheer diversity and (one might argue) fragmentation of Linux means this won’t be a quick fix. In fact, it might not be a fix at all if patches aren’t applied as we known many won’t be on past experience.
Because of Bash’s power, some alarmed voices are already talking of the potential for a Bash worm, spreading from system to system like a reprise of SQL Slammer. That seems a little premature.
The larger issue is how the public calibrates their sensitivity to these types of complex and sometimes pretty arcane warnings, which now seem to emerge with tiring regularity. Bash could end up sounding like the sysadmin equivalent of the data breach everyone is convinced affects their neighbour’s personal details but not theirs.
If explaining Heartbleed to the public was a challenge, communicating the nature of the Bash ‘shell shock’ flaw is going to strain TV script writers and anchors to breaking point. Such is the nature of contemporary security, built on a morass of complex systems nobody ever expected to have to prise open to fix weaknesses. Security is still a horribly manual process and it is this rather than Bash that is the real flaw.