A blog about SCAMP (Small Craft Advisor Magazine Project) boats. Covering the build, sailing the boat and the scamp community that has formed around this little portly boat.

Tuesday, September 30, 2014


Shellshock is a vulnerability that may allow a remote attacker to execute code on your server. Remote code execution is very bad. It may allow an attacker to retrieve your passwords, add your machine to a botnet or even launch attacks against other machines. These attacks are possible when untrusted user input is passed to a program called bash, something you've probably never heard of before.

BASH is a shell; a program that is an intermediary between you and the complicated parts of a computer. The shell is meant to soften the user interface to the computer, it does automatic path searching, filename expansion, and many other tasks. Bash is meant to be used at the command line, but GUIs are usually considered shells as well. Bash is also used as an intermediary between computer processes; when one process wants to start another process, it often sends the command line to bash, who processes it and executes the new program.
BASH (Bourne Again Shell) was written by David Bourne in 1977. Over the years, we've enhanced bash to be a full fledged programming language, complete with syntax, functions and what we call an environment; the area where variables are stored.
We've even enhanced bash to execute code from the environment.
That's where the problem lies.

In some web application frameworks, the headers of a web request are put into the environment by the webserver. In the shellshock attack, a malicious user submits a request that has headers that look like this:
User-Agent: () { :;} #malicious code goes here
The first important bit is the (), which creates a function. The second important bit is the last part. I've used the # which means a comment, but the attacker could put anything in there and your machine will execute it.
The header is put in the environment by the web server before executing a subprocess to serve a webpage. Bash does it's job and happily executes the malicious code before executing whatever back-end program it is supposed to execute.

The attack shown above works on a particular framework called CGI, but the method of sending untrusted, unsanitized input to a program is not unique and can be exploited in a lot of ways.

In many ways, this attack is worse than April's heartbleed. Remote code execution is far worse than mere information leakage. However, this attack is used against servers, so the average user won't see the attack.

No comments:

Post a Comment