Bash “Shellshock” vulnerability – what you need to know


What is “Shellshock”?

shellshock-170Shellshock is the media-friendly name for a security bug found in Bash, a command shell program commonly used on Linux and UNIX systems.

The bug is what’s known as a Remote Code Execution vulnerability, or RCE.

This means that someone who isn’t already logged on to your computer might be able to trick Bash into running a program that it wasn’t supposed to.

Officially, the bug is documented as CVE-2014-6271 and CVE-2014-7169.

What’s a command shell?

A command shell is a program that helps you run other programs on Linux and UNIX, much like the Command Prompt on Windows.

Bash stands for “Bourne Again Shell” (a pun celebrating that it was derived from an earlier shell written by Stephen Bourne of Bell Labs).

You can use Bash interactively, typing in commands and immediately viewing the output, or as a tool to help you run a series of programs specified in a text file called a shell script.

If Bash is meant to help you execute code, how can it have a “code execution” bug?

A code execution bug in a program that is supposed to run commands for you does indeed sound like a contradiction.

But Shellshock exists because it is possible to trick Bash into running a program when you wouldn’t expect it to.

That may allow a remote attacker to send you text that you hand over to a Bash script as harmless looking data, only to find that it gets processed as if it were code, or program commands.

This sort of trickery is often known as command injection, because it involves sneaking in operating system commands, hoping that they get run by mistake.

Doesn’t server software take care with the data it feeds to Bash?

Server software that passes user-supplied data to Bash (and other installed programs) is usually very careful to watch out for known tricks.

For example, a Bash command line that contains a semi-colon is actually treated by Bash as if if were two separate commands.

So the Bash command:

echo Be careful; rm removes files

looks as though it ought to echo (i.e. print on the screen) the text Be careful; rm removes files.

But the semi-colon effectively turns it into two commands in sequence, first echo and then rm, which is the UNIX command to remove, or delete, files.

So the single line above actually ends up doing this:

echo Be careful    ← Echoes "Be careful"
rm removes files   ← Zaps the files "removes" and "files"

The semi-colon turns rm into a command in its own right, thus causing a command injection error.

For that reason, server software usually looks out for various characters and constructions that have special meanings to Bash.

Anything that looks dangerous is blocked, or altered to make it safe (known as sanitising in programming jargon).

How come “Shellshock” attacks aren’t blocked too?

The problem is that, unlike the semi-colon example above, no-one knew what to watch out for until this bug was found.

The Shellshock bug occurs in a part of Bash that allows you to define functions, which is what programmers call a sequence of commands that are saved up for later.

In theory, defining a function, even a dangerous or malicious one, is harmless provided that the function never actually gets used.

So an unexpected semi-colon in command data passed to Bash ought to raise suspicion, but unexpected function definitions ought not to matter.

Because of the Shellshock bug, however, Bash can be tricked into running commands specified in a function definition, instead of storing them up harmlessly and not using them.

How do we fix this?

Update the Bash program so that it processes function definitions more carefully, and doesn’t run commands it isn’t supposed to.

Is an update available?

A reliable and complete patch for Bash is not yet ready. [2014-09-25T10:00Z.]

A partial fix exists, but it doesn’t fully solve the problem yet.

What about Sophos appliances and products?

As far as we are aware, none of Sophos’s Linux or UNIX products use Bash in a way that would allow this vulnerability to be exploited with data supplied by an attacker from outside.

Briefly put, attackers would need access to a Bash command shell first before they could use the bug to get access to a command shell.

Nevertheless, we intend to update any Sophos-supplied versions of Bash once a reliable and complete patch is ready and tested.

What about Sophos servers and services?

As far as we are aware, none of our servers or services could have been exploited due to his bug.

This includes our internal business systems, Sophos web servers, update servers, partner portal and support forums.

For further information

For further information, please visit Sophos Knowledgebase Article 121444.

Images of cartoon bomb and oyster shell courtesy of Shutterstock.