Tried, Tested and Proven

A new bug has been discovered by Stephane Chazelas in the Bourne-Again Shell (BASH). For Linux and other UNIX variants the shell is fundamental to the operation of the system and for a flaw to be found in this is serious problem. We have noted that some industrious journalists are already terming the problem BASH-Bleed, supposedly in reference to the well known and recent Heartbleed vulnerability. In contrast to the Heartbleed bug, which potentially exposed sensitive data which may have lead to user accounts becoming compromised, a Shellshock attack is a direct compromise of the server and all of the data therein.

What does this mean for me?

For a general user of the Internet it means that the web sites you normally visit may become compromised and the content of those websites changed. This could be simple defacement, data theft or even that the websites are modified in a way that attacks visitors.  For system administrators this means that your server may become compromised.  This could lead to a loss in reputation or data with which you are trusted. It could also lead to the loss of your weekend if you don’t patch before you get compromised.

What is my exposure?

Under normal circumstances the shell will not be exposed to unauthenticated users of a system. If it were they would be able to execute arbitrary commands on the host potentially leading to the complete compromise. The problem with the Shellshock bug is that it can be triggered remotely when exposed services interact with the system shell. For instance you may have a web application that makes a call during its operation to the system shell. This would normally be fine as the user cannot control the command that is executed. The Shellshock bug means that a remote user who is interacting with such a service can cause the shell to execute what they request rather than what was predefined.

The bug revolves around how environment variables are processed by the BASH shell. At this point in time is would appear that many common configurations are susceptible to the issue.

In Linux there are many different services which interact with the system shell. For instance it has been reported that some DHCP servers are vulnerable to a Shellshock attack. This means that careful consideration has to be given to which services are exposed to which users. By far the most common exposure will be though a web site. If you are using CGI scripts you are likely to be vulnerable. If you are using a PHP application that makes system calls such then you may also be vulnerable. The warning on this bug is that there is potential that every service offered by a server may at somepoint call the system shell so may be attackable in this way.

Technical Detail

The fundamentals of the bug and how it can be triggered relate to how bash programs export function definitions from a parent shell environment to child shells. In order to exploit this behaviour an attacker must utilise a specifically crafted environment variable value containing “() {“. These are then sent and parsed by the shell prior to a program’s execution. The obvious danger with this type of vulnerability is where user supplied values are able to be passed on to a program and subsequently parsed by the BASH shell. An example being POSTs to web servers, where user modified data can be sent within HTTP Headers as well as in form data.

The Portcullis technical team have seen a large number of attackers scanning for this vulnerability over recent days.  Web log entries like the following are currently commonplace:

x.x.x.x - - [24/Sep/2014:23:17:31 +0100] "GET /somepage HTTP/1.1" 200 14685 "-" "() { ignored;};
/bin/bash -c '/bin/rm -f /tmp/f; /usr/bin/mkfifo /tmp/f;cat /tmp/f | /bin/sh -i 2>&1
| nc -l 1234 >; /tmp/f'"

Here you can see the attacker has replaced their “User Agent” (a HTTP header field” with a malicious attack string.  They are trying to use netcat (nc) to get a remote shell.  Unfortunately in this case they’ve neglected to replace with a sensible IP address to listen on, so probably won’t be having much success!

What can I do?

Whilst there is a formal patch available there have been numerous reports that it deals with the outcome of the bug rather than the root cause, i.e. the shell will still parse data starting with () {. As we do not see the current fix as fully robust we would make these recommendations:

  • Upgrade your current version of bash to one that fixes CVE-2014-6271;
  • Review all your web/CGI scripts for #!/bin/bash entries;
  • Modify scripts using /bin/bash to another shell, i.e. /bin/sh Ensure your chosen replacement shell is not simply a symlink to bash
  • Modify the /bin/sh symlink to point to another shall such as dash – This may have unexpected consequences so test fully first.
  • Review your web logs for repeated use/unusual use of scripts
  • Follow the security email lists for your platform, for example the Debian Security Advisories, can be found here:
  • Carefully review all of the services exposed minimising those exposed to untrusted networks.