BASH vulnerability: All you need to know

The BASH vulnerability has been dubbed one of the most serious vulnerabilities ever to be discovered and like Heartbleed back in April, has left many system administrators (Linux, UNIX and Mac OS X) scrambling for cover.

TechRadar Pro questioned Craig Young, security researcher at Tripwire, on the subject of GNU's Bourne Again Shell's affliction, and then we also spoke to Kaspersky Lab's David Jacoby to get his take on the matter (you'll find that interview on page two).

TechRadar Pro: What is the vulnerability?

Craig Young: An Akamai researcher discovered that BASH, the dominant command-line interpreter present on Unix/Linux based systems, will improperly process crafted variable definitions allowing trailing bytes to be processed as OS commands.

BASH allows users to define environmental variables which contain function definitions and a flaw within this parsing process means that commands specified after the function are executed when the variable definitions are passed to a bash interpreter.

The problem can easily be reproduced by logging into BASH shell and defining a crafted variable definition with trailing commands but in this scenario there is little to know risk since the commands are limited to the permissions of the already logged in user.

Where this 'shell shock' vulnerability really becomes a problem is when we consider the many ways in which BASH is indirectly exposed to an adversary.

The most prominent (and worrisome) example of this is web technologies which use the vulnerable command-interpreter to generate responses to HTTP requests.

Since various details from the request are stored in BASH variables and passed to the command-interpreter, a remote unauthenticated attacker can use these scripts to inject commands which will run in the context of the web server.

TRP: When can this vulnerability be exploited?

CY: If an attacker has control over the definition of even a single environment variable imported into a bash environment, they can trigger the execution of arbitrary commands.

Although it is likely that researchers will continue to recognize new vectors for this attack, the most prominent vector is the common gateway interface (CGI) particularly when bash is used to drive the script.

This process is vulnerable because various request components (header values, protocol version, etc) are provided to the underlying bash script as environment variables.

For example, the Apache web server will set an environment variable HTTP_X_CVE_2014_6271 when a CGI request contains the header 'X-CVE-2014-6271: '. Specifying a header value with the form '() { :; }; command;' will then be presented to bash as something like:

HTTP_X_CVE_2014_6271 = () {
:;
};
command;

The result is that 'command' is immediately executed rather than being contained within the variable definition. In general any scenario in which untrusted user-input is placed into a BASH variable opens the door for exploitation.

Beyond web sites, Red Hat's security team has highlighted several other vectors including network exploitation through a rogue DHCP server and privilege escalation by way of SUID scripts using variables set by an untrusted user.

TRP: What can an adversary do?

CY: Successful exploitation of the CVE-2014-6271 'shell shock' vulnerability allows execution of arbitrary commands as whatever user the BASH script is processed as.

The impact therefore will vary based on the attack vector with the most severe impact of course being when an attacker can influence variables used in a privileged script such as the case with a rogue DHCP server.

Administrators will more likely be concerned with the web based attack vector due to the ease of anonymous remote exploitation but by itself. In this scenario, an attacker may be able to disclose source code, delete entire web sites, or access an interactive shell.

Fortunately best practices for web server configuration dictate that servers run as a low privileged user such as 'www-data' which will limit what an attacker can do.

The risk of course becomes much more serious when coupled with a local privilege escalation vulnerability. Many administrators are slower to patch vulnerabilities which are only exposed to local users so this multi-staged attack scenario is in fact very realistic.

TRP: What can administrators do for protection?

CY: Patches are available to resolve the behavior by fixing the way in which BASH parses function definitions. Deploying these patches should be very high priority especially on Internet facing systems which make use of BASH to handle HTTP requests.

If there is anything we learned from heartbleed however it is that it can be daunting to find all the places a vulnerability may be exposed and some web servers are so inconvenient to update that patches can be delayed for a prolonged period of time.

In this situations, other technologies can help minimize risks. Intrusion prevention systems (IPS) for example can prevent malicious looking data streams from reaching a server and file integrity monitoring (FIM) can alert administrators if an attack does reach the server.

TRP: Now for the big question, 'worse than Heartbleed?'

CY: The broad range of potential attack vectors makes it very difficult to directly compare heartbleed to shell shock. The question of whether heartbleed is worse than shell shock is entirely dependent on the role and configuration of affected servers.

While the OpenSSL vulnerability could be readily exploited on any system with a web server running an affected OpenSSL, it does not hold true that all web servers running an affected BASH version are vulnerable. (Web servers must have a vulnerable bash interpreter as well as some server-side script which uses BASH with attacker controlled variable definitions.)

Although typically I would call a command injection a far more serious risk than a buffer over-read, it does depend on the how the server is used. Heartbleed can easily and stealthily be used to expose private key material and passwords which may not be directly accessible in an unencrypted format to a shell shock exploit.

Heartbleed can also expose session tokens and account credentials used to gain administrative access without the presence of other vulnerabilities whereas the BASH issue alone will not generally lead to root access through a web request.

The threat model however completely changes when considering an attacker positioned on the network to do things like setting up a rogue DHCP server but generally speaking there are a lot of malicious actions which can be performed from this privileged position on the network.

So in conclusion, my answer to the question of 'Is shell shock worse than Heartbleed,' is an emphatic "It depends."

Speaking of Heartbleed, can't believe it's nearly six months since it was first discovered.