(With apologies to John Brunner for stealing and mangling the title of one his books which happens to be a considerably appropriate choice)
What?
The Shellshock vulnerability, where a 23-year old vulnerability in the bash Unix shell can sometimes be exploited by attackers to run their own code on a vulnerable server. So far this vulnerability has been found to be exploitable with certain popular services running on Unix-based systems (including Linux).
Why?
Because I happen to be one of those going around telling people to fix their servers. And because I needed a place to mouth off about some of the more idiotic reactions I have encountered.
How Bad Is It?
Well it’s unlikely that this will cause the collapse of human civilisation, and it’s probable that your fridge will continue to work.
It’s like being asked how long a piece of string is whilst you’re still hauling it in and have not found the other end yet. It could be a great deal worse than expected or a bit of a damp squib :-
- The exploits may be much harder to make use of than expected. An attacker needs to find the vulnerable scripts on the web servers out there, and unless a very common web applications is found to be vulnerable, this may not be that easy to find.
- There may be a lot more vulnerable devices out there than expected – all of the embedded devices that idiots are assuming are safe because they come with BusyBox could have bash installed as well because some developer found that their script worked with bash and not BusyBox.
- An attacker may accidentally release something like SQL Slammer and cause widespread disruption.
Ultimately we have to wait and see how bad it is likely to be. Peering in to a crystal ball is always dangerous but my best educated guess is that :-
- We won’t see an Internet melt-down.
- Some sites will be broken into and some of those will have data leaked. This will happen anytime between 23 years ago (yes it could have been exploited in the past) and 23 years from now.
- Some unexpected ways to exploit this vulnerability will be discovered – for example there are plenty of people who believe that Windows is safe from this; as it happens my Windows 2012 server does have bash installed on it.
Bash? Unix Shell?
Most early operating systems were controlled with some sort of command line where you would enter a command at a terminal, hit return, and then the computer would respond to your commands – a bit like DOS whose descendent can be discovered on a Windows system if you ever run cmd.exe. One of the innovations introduced by Unix was the concept of the user selecting which command processor to use and this command processor become known as the shell.
Most Unix shells allowed some level of programming initially to make repetitive interactive tasks easier to perform, but this eventually become shell scripting where useful functions could be made available persistently and to other users by writing a sequence of commands into a file.
The concept of replaceable shells allowed early Unix users to chose between various different shells – initially the Bourne shell (sh), and the C-Shell (csh), with improved shells coming along over time – the TENEX C-Shell (tcsh), the Korn shell (ksh), my shell of choice: Z-shell (zsh), and of course the Bourne Again Shell (bash).
The Vulnerability
Unix (and Linux … and Windows too) have the concept of environment variables where variables can be set to some value and that value will be available to child processes. As an example, the PATH environment variable is set when someone logs in, and is used to specify where to search for programs that are not supplied with a full pathname.
For instance, if you were to enter the command ls into a terminal window, this would be translated to the absolute path /bin/ls or c:\cygwin\bin using a the PATH environment variable.
Bash has a feature where it allows shell functions to be defined within an environment variable; however trailing code following the function is run.
Normally that would not matter, but when an attacker can provide the contents of the environment variable, then that attacker has a way of running their own code where they should not be able to.
Because it is the most serious way of exploiting this vulnerability discovered so far, everyone has concentrated on exploiting this vulnerability through a web server.
Most web servers use environment variables as a way of passing information about a request (i.e. data supplied by an attacker) to any scripts they run; when this script is a bash script or the non-bash script invokes another program via bash (very common amongst lazy programmers) then an attacker can run their own code on the server.
So What Is Vulnerable? And Exploitable?
Let us distinguish between vulnerable where a program with a serious flaw is installed, and exploitable where an attacker can make use of that vulnerability. Because if you just fix situations where a known exploit exists, you are still exposed to unknown exploits. And it is distinctly possible that attackers will develop more and more ways of exploiting this vulnerability over time.
The short answer to the question of what is vulnerable is that every device with bash installed is vulnerable.
To those thinking that only Linux servers are vulnerable, the list of what is vulnerable will probably come as a bit of a surprise :-
- It should be assumed that all iThingies (iPhones, iPads, etc.) have bash installed. After all, OSX has been confirmed to be vulnerable and the iThingies run something very similar.
- Android phones can run bash and it may be installed by default. If it is, then it is vulnerable.
- Windows machines do not come with bash installed by default, but that does not mean that it has not been installed at a later date. Any large corporate application that started life as a Unix-based application may well have an installation of bash lurking somewhere within it.
- Similarly for any other non-Unix based servers (VMS, IBM Mainframes, etc.). In fact I would not be surprised if the proportion of IBM mainframes with a vulnerable version of bash installed is surprisingly large.
- Embedded devices, or the Internet of Things. One of my pet peeves is the assumption that because people usually find BusyBox installed on devices they are familiar with, that they assume that all IoT devices have BusyBox and not bash. All it takes is one developer who finds their funky script doesn’t work with BusyBox but does with bash to result in an IoT device to have bash installed.
In the long term, it is possibly the last category that is the most exploitable because such devices are rarely updated, are assumed to be safe, and are frankly the most likely to be running rancid code that is easily exploitable.
Mitigations
With worms actively exploiting this hunting down all the vulnerable web servers, it’s time to ask about means to limit the damage :-
- Why haven’t you patched yet? Hasn’t the vendor released the patch? If not, go and shout at them.
- Turn off any services that you don’t need. Now.
- Why does your web server need to make connections to the outside world? First indications are that the worms out there at present download a second stage to start behaving badly. If your server can just do it’s job but cannot download stuff then any worm won’t be able to fully activate. This is not a panacea as you can still be exploited, but you cannot be automatically exploited.