Introduction

Shellshock is a fatal bug in found in the popular Bourne- Again Shell or Bash. This bug was publically disclosed on 24th Sept 2014 by security researcher Stephane Chazelas. This bug had been affecting all the versions of Bash thus making it one of the most fatal security bugs in the recent times.

But, what is a shell in the first place? The shell (also known as the command shell) is by far one of the most important software on a *nix based system (including linux). At minimum, it takes commands from the users, finds out where they are installed and executes it.

There are a plethora of shells available for Linux, ranging from the nimble Almquist Shell all the way to the behemoth that is ZSH. But, by far, the most common and widely used shell is the Bourne-Again Shell (Bash), which was based on the original Bourne shell of Unix.

Aside from the functionality of executing commands given by the user, Bash (as well as other shells) can also read said commands from a file and execute them. These files, called shell scripts are a fundamental building block of starting, functioning and maintenance of a Linux system.

These scripts need not just be a sequential list of commands to be executed in order. A Bash script is essentially a programming language on its own, supporting features like variables, loops and functions. A function is defined starting with () {}. The part within the curly braces { } is considered to be the part of the function.

Example:

  function () {echo hello world}<br>
  VAR=() {echo hello world}

Another important feature in bash are environment variables. Environment variables are global variables that are generally used to provide a context to the program like, username, home folder location and temporary file. These variables provide information about the environment and affect the way the processes behave on the system.

When a process is created, it inherits a duplicate of all the environment variables from the shell. As an alternate, it is also possible to modify these values that are passed to the child process. The `env` command can be used to do that.

The child process can also be another Bash shell. And in that case, we can pass functions as environment variable too. When that happens, the child bash shell, converts the function definition to an internal representation. There is a vulnerability in the implementation of this feature in Bash.

Bash allows us to export shell variables as well as functions to other bash instances(Child process). Thus the child process.

The critical vulnerability that was discovered in Bash was that if there was a code/command appended after the function definition and if this function was exported into another child bash process, - This appended code/commands were being executed in the child bash instance.

Structure of a declared function:

$   SomeFunc=() { some legitimate action ; } ; Code1;

Here ‘SomeFunc’ is the declared function and ‘Code1’(and the remaining commands/codes mentioned thereafter) is a /are malicious code that has been appended after the function declaration.

Example:

$ XFunc= () { echo  &ldquo; WYSIWYG&rdquo; ;};  top;

Ideally Bash should not execute anything after the function declaration (i.e XFunc in our case). But if the above code in our example is imported by another bash instance (child) the command top would get executed and print the list of running processes.

To demonstrate this lets declare a function and export it to another bash instance.

Case 1: This is how functions would be declared and exported in the Uthopian World .

  &gt;$  env XFunc=&rsquo;() {  :/tmp/;};&rsquo; bash –c &ldquo;echo Uthopian World&rdquo;

clip_image002

Here the environment function XFunc is defined and imported by another instance of bash and the result are as expected.

Case 2: This is how functions would be declared and exported in the real world.

&gt;$ XFunc=&rsquo;() { :/tmp/;}; top&rsquo; bash  –c &ldquo;echo Uthopian World&rdquo;

clip_image004

Now here XFunc is defined and after the definition the command “top” is defined. In Linux ‘top’ is a commandline utility that displays a listing of the most CPU-intensive tasks on the system, and can provide an interactive interface for manipulating processes. So here the moment the function is exported the appended command (top) also runs.

Case 3: Guess what happens when you do something like this …???

&gt;$   XFunc=&rsquo;() { :/tmp/;}; bash;&rsquo; bash –c &ldquo;echo Uthopian World&rdquo;

clip_image006

How To Identify & Fix the ShellShock Bug :

  1. Enter 
    <strong><em>env x='() { :;}; echo vulnerable' bash -c &quot;echo  Testing for ShellShock&rdquo; </em></strong>

    in the bash.
    If you receive the following output, your system is vulnerable.

    <strong><em>&gt; vulnerable</em></strong>
    <strong><em>&gt; Testing for ShellShock</em></strong>
  2. To Fix this bug update Bash to the latest version.
    For Debian based Machines (eg. Debian, Ubuntu, Kali) 
    $&gt; <strong><em>sudo apt-get update  &amp;&amp; -y apt-get install bash.</em></strong>

    For Red-Hat based systems (eg. CentOS,Fedora,Red-Hat)

    $&gt;<strong><em> sudo yum update bash</em></strong>
  3. Restart Bash after it has been successfully updated and now re-enter 
    <strong><em>env x='() { :;}; echo vulnerable'  bash -c &quot;echo Testing for ShellShock&rdquo;  </em></strong>

    in the terminal to check if the patch has been installed successfully.
    You are safe if the output reads as :

    <strong><em>&gt; Testing for ShellShock</em></strong>

    References:

    1. http://seclists.org/oss-sec/2014/q3/650
    2. http://garage4hackers.com/entry.php?b=3087
    3. http://en.wikipedia.org/wiki/Shellshock_(software_bug)
    4. https://access.redhat.com/articles/1200223

     

    Authors

    Jovin Lobo , Rishi Narang; Naresh T A