Bashing Linux Security – The Shellshock Exploit
On Wednesday the world awoke to a substantial vulnerability in the Bourne again shell, otherwise known as bash. Bash is a UNIX like shell which was created in 1980. It is now a far cry from the simple terminal based command interpreter it used to be, having grown arms and legs in terms of functionality and has become one of the most installed utilities in Linux systems worldwide.
Exploit Intro
The vulnerability was first discovered by Stephane Chazelas, listed as advisory CVE-2014-7169, this has graduated to CVE-2014-6271 as the first fix released by Red Hat was unsuccessful. The problem stems from bash allowing arbitrary code execution. Several services and applications are vulnerable to unauthenticated attackers being able to provide environment variables remotely. These environment variables are important because they can directly influence software behaviour.
The bash shell is often used remotely by users, for example using ssh to administer a system or service, many programmers run the bash shell in the background and bash provides parsing for services such as Apache and has limited command execution support.
Impact
Attackers exploit this vulnerability by creating environment variables with specific values before summoning the bash shell. Variables can possess any name and could contain malicious code. This code is then executed when the bash shell is called. This will raise many eyebrows as the many ways of calling bash via applications makes this issue perilous. It is not uncommon for an application to execute binary code by invoking Bash. The widespread use of bash makes this vulnerability serious and remediation must be fast and effective.
Ease of Exploit
We are aware of exploit code in the wild, which is trivial to use.
Major attack vectors reported so far are HTTP requests and CGI scripts. AcceptEnv variables in OpenSSH are also open to attack, including TERM and SSH_ORIGINAL_COMMAND. Environmental variables, named arbitrarily, can contain vicious payloads that seek to exploit the network.
Web applications in PHP, Python, C++ or Java may also be vulnerable if they happen to use libcalls, which are backed by calls to libraries-linked to bash. For example, popen() or system() are both linked to calls to bash.
Test your Bash
Test your version of bash for this vulnerability by running the following command:
$env x='() { :;}; echo I am vulnerable to ShellShock' bash -c "echo This is a test for CVE-2014-7169"
If the command output as follows:
I am vulnerable to ShellShock This is a test for CVE-2014-7169
Then your version of bash is vulnerable.
If your version of bash is not vulnerable then your output should be similar to:
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test for CVE-2014-7169
Mitigation
Unfortunately the patch released by the maintainer of bash will not fix the vulnerability. Its attempts to sanitise code have been shown to be unsuccessful.
There are bash workarounds which may mitigate the vulnerability, however due to the limited testing of these solutions you may find that your fixes have unintended consequences. However for those that can’t afford to wait, the fix involves upgrading to a new version of bash and imposing access limitations for vulnerable services. Additionally, filtering the input to vulnerable services such as HTTP is advisable, a Python script that tests URL’s for vulnerabilities can be found on GitHub, contributed by Andres Riancho.
Alternatively, whilst it may not be a practical solution for many, you can replace bash with a different shell.
Update
26-09-2014
Patched versions of bash that fix CVE-2014-7169, have been released by Red Hat. As reports grow of Shellshock being actively exploited, it is strongly recommended that this update be applied as soon as possible.
The fixes apply to Red Hat Enterprise Linux 5, 6 and 7. However it is important to note that updates are applied after you have made changes to your applications that create bash functions as environment variables.
The patch that fixes Shellshock changes how bash evaluates environment variables. This means that any application which creates bash functions as environment variables will need to be updated in line with the patch changes.
To see if your bash is still vulnerable run this command:
env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
If your version of bash is still vulnerable the above command will result in the output “vulnerable”, this stems from the function name needing to be stored in an environment of the same name.
This means that if a function is named “compute” it would be stored in an environment variable named “compute”. After applying the update, the aforementioned function would be named “BASH_FUNC_compute()”. There are now two pairs of parentheses in the environment string, as in “BASH_FUNC_compute()=() {}”.
If after running the test above, you have found your system is vulnerable and are certain your associated applications are updated then update to the most recent version of bash by running:
# yum update bash
You will now need to restart your bash-linked applications to ensure that future environment variables are created using the new version of bash. A reboot of your system and services is not required as the vulnerability stems from initial imports of the kernel process environment. If the update is successfully installed then new processes will use the new code and Red Hat asserts that it will not be vulnerable.
If you believe your system may have been compromised by Shellshock then it is advisable to reboot your system after updating bash. Additionally security checks should be analysed to identify suspicious activity.