Everything you need to know about the Shellshock Bash bug


There is a new vulnerability called the Shellshock Bash Bug. What you need to know is that the bug leaves unpatched systems open to a variety of malicious and remote attacks. Bash is commonly used by web servers, so in theory it could be used to take over entire websites. Internet connected devices like web cams are similarly vulnerable. But worst of all, since there’s a decent chance your computer is running Linux in the background, an attacker on your network could use the bug to extract personal information from your machine.

But the main reason people are comparing Shellshock to Heartbleed is that the distribution of the bug is unknowably vast. Bash is baked into so many systems and has been around for so long that in all likelihood, the bug will never be fully fixed. This is vulnerable software that has been spreading across the technological world for years and years.

You can get detailed information from this article by Troy Hunt.

They go on to rate it a “10 out of 10” for severity or in other words, as bad as it gets. This is compounded by the fact that it’s easy to execute the attack (access complexity is low) and perhaps most significantly, there is no authentication required when exploiting Bash via CGI scripts. The summary above is a little convoluted though so let’s boil it down to the mechanics of the bug.

The risk centres around the ability to arbitrarily define environment variables within a Bash shell which specify a function definition. The trouble begins when Bash continues to process shell commands after the function definition resulting in what we’d classify as a “code injection attack”. Let’s look at Robert’s example again and we’ll just take this line:

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

The function definition is () { :; }; and the shell command is the ping statement and subsequent parameters. When this is processed within the context of a Bash shell, the arbitrary command is executed. In a web context, this would mean via a mechanism such as a CGI script and not necessarily as a request header either. It’s worth having a read through the seclists.org advisory where they go into more detail, including stating that the path and query string could be potential vectors for the attack.

Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell and indeed some are recommending this. In many cases though, that’s going to be a seriously breaking change and at the very least, one that going to require some extensive testing to ensure it doesn’t cause immediate problems in the website which in many cases, it will.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s