Shell Shock

What impact does the shell-shock vulnerability have on us?

The recently uncovered and talked about vulnerability in the Bash Shell, also being called the Shellshock, has fairly wide reaching consequences for smart appliances, our personal computers and servers. The last big vulnerability to attain this kind of scope and attention was Heartbleed and rightfully so. While Heartbleed could be used to do things like steal passwords from a server, Shellshock can be used to take over the entire machine. But this one seems to be worse according to Robert Graham (@ErrataRob). Even though the vulnerability is fairly complicated, I want to try to simplify it and explain here. In this narrative, I want to cover in detail what this vulnerability is, how can systems with shell-shock be targeted and what are its implications.


So let’s get started with what is Shell Shock. Linux systems all use a command-line shell, which is an interpreter that provides a user-interface to interact with the operating system. The users interact with the shell by directly inputting the commands and obtaining an output. There are many varieties of shells, (for instance Zsh) but one of the most popular ones is Bash. Originally, Stephen Bourne wrote the Bourne shell which later on got replaced by Bash as a part of the GNU-Project. Bash has become the standard in many Linux-distributions and I suspect that it’s the only shell available on Mac OS X. Being this ubiquitous, any problems in Bash are also just as wide-spread and Shellshock is one such problem that has been there in Bash since its first release only now to be discovered. In a nutshell, a system with shellshock vulnerability allows an attacker to run an arbitrary code of their choice on the target machine. This is a huge problem for many reasons, Bash is not only used by users to interact with the OS, but in the case of servers, numerous applications rely on Bash for some sort of processing. Also all of Enterprise Linux based on Bash is also vulnerable, so patching this bug is not as easy as it may seem. PHP (a backend language) uses Bash and so a carefully crafted piece of code can extend through Bash to a higher-level framework like PHP and cause malicious unintended actions. Graham also says that it might be impossible to catalogue the software that is vulnerable to this bug. One of the easier ways to eliminate a bug is to contain the breach of its scope but shellshock seems to be particularly difficult in that respect. By default, it is safe to assume that you are vulnerable and this website provides a utility to test for the vulnerability on your system1

Aside from software, most networking hardware also runs and uses UNIX-based embedded systems. They are all vulnerable to this problem, and what makes it worse is that attackers might be able to reach those systems long before they are patched (if ever). This is alarming because security experts think that short-term attacks might be able to cause a SQL-slammer type global problem. Other man-in-the-middle type attacks are also very likely and extremely dangerous for all the networking infrastructure build on top of these compromised devices, CloudFlare already reports several attacks being carried out and they rolled out new firewall rules. Developers from the GNU-Project released a preliminary fix which was later on pointed out by Secunia Security. In the true sense of panic, this is the first time we have seen such a huge number of machines left vulnerable and open. How they get patched up and when that will happen, also the likelihood of that patch being sustainable are all up in the air. This is akin to opening a Pandora’s box in regards to every vulnerable machine.


The NIST marks this bug a solid 10/10 in terms of its severity and what makes it so severe is in part that there is no authentication required when exploiting Bash. Generally some commands executed require super-user privilege but in shellshock, we don’t need any level of commands can be executed at all. Let’s handle the simple case of web-servers. The websites we browse on the internet are hosted behind a server that uses software such as Apache to serve the webpages. Now generally viewing a website happens almost automagically, you type the URL in the address bar and reach the page, but the request to serve the page can also have parameters. These are common parameters like http-user-agent which tells the server if the user is using Firefox, chrome or IE. Another more interesting parameter is that of http-header. This one defines the header-request that is being sent to the server, a specially crafted request is the crux of Shellshocker.

Bash has provision for something called environment variables. These are named data-objects which are defined globally so any application can access them. Often these variables are used as shorthand for some function-definition, developers write their own to make their life easier as server admins. Therein lies the vulnerability, let’s take a look at a seemingly-innocent request:

http-header = Cookie:() { :; }; ping -c 3

Here the header contains a HTTP cookie, but that’s not very relevant, this is just one way to demonstrate the attack vector (or means by which the vulnerability can be exploited). The function definition is present right after in the { :; }; followed by the shell ping command. The ping command is harmless but in the context of a server, this gets executed without any authentication The ping may very well be replaced by anything else that can be executed in Bash. There are several mechanism (vectors) through which an attacker can have a target machine execute arbitrary code such as CGI but this is only one case we are talking about: HTTP, if we start to throw in other protocols such as Telnet and SSH, the scope of shellshock increases dramatically. The real question here is that what can an attacker do when he has access to shell on any vulnerable machine? Getting shell-level access has always been a major win for an attacker but even then there are some restrictions on what they can do. In the context of shellshock, they don’t need any auth. which makes it much more dangerous.


What’s the next step after having shell-access? An attacker would want to be able to access files and write to the system. This is potentially the most dangerous consequence of this vulnerability. Much like Zeus a version of malware exploiting this worm can attach a JavaScript based vector to propagate the attack. There are people working on exploiting this right now, and then we have security experts working on a fix. It’s always been a race like this and one major advantage that attackers have is the edge they get from the scope of the bug. Here the scope is incredible vast: Just imagine, how many machines do we use that are connected to the internet every single day? On top of that, how many use Linux? Lastly, does the average Joe even know which of them use Linux? My case is rested. I’m talking about the Internet of things (IoT) that encompasses the ever-increasing number of devices being inter-connected in our lives. In a more scary version but certain possible in the upcoming months is the routers. How many people know how to upgrade your Router firmware much less patch it? These are the kind of devices that might remain forever out of reach and in the same sense, forever exploitable. This gets worse with devices running embedded Linux and using Bash as the only shell.

What about smart-devices? This is the next frontier we will see being breached. Most iPhone users have jail-broken their iOS installs, in the process they basically install a shell that gives them free-access. This is problematic because Apple doesn’t really want you to do that, but people do it anyways, the downside is that these devices are even more at risk because the users have now allowed a much wider-level of access than was previously possible. Android isn’t left alone by any means either. Attacking smart-devices in this manner not only causes panic but the short-term attacks might sabotage the devices long before the patches are pushed out. This really is like opening a Pandora’s box, what happens next is absolutely unpredictable on so many fronts and I would love to cover as much of it as I can. If there is enough interest, I will definitely make this a post-series.

In the end, I think as a security-researcher, this is incredibly exciting. What’s going to happen next in terms of who reaches the target machines? The patch or the attackers? Initial patches have been shown to be incomplete, so does that simply buy more time for attackers who have already started exploiting the machines? Lastly what is the scope of shellshocker to enterprise Linux? Sit back and watch, this vulnerability is definitely going to send big waves.

  1. The CVEs listed for the shellshock include CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277