Shellshock Bug Spells Trouble for Web Security

[dlevere]

By Brian Krebs

As if consumers weren’t already suffering from breach fatigue: Experts warn that attackers are exploiting a critical, newly-disclosed security vulnerability present in countless networks and Web sites that rely on Unix and Linux operating systems. Experts say the flaw, dubbed “Shellshock,” is so intertwined with the modern Internet that it could prove challenging to fix, and in the short run is likely to put millions of networks and countless consumer records at risk of compromise.

The bug is being compared to the recent Heartbleed vulnerability because of its ubiquity and sheer potential for causing havoc on Internet-connected systems — particularly Web sites. Worse yet, experts say the official patch for the security hole is incomplete and could still let attackers seize control over vulnerable systems.

The problem resides with a weakness in the GNU Bourne Again Shell (Bash), the text-based, command-line utility on multiple Linux and Unix operating systems. Researchers discovered that if Bash is set up to be the default command line utility on these systems, it opens those systems up to specially crafted remote attacks via a range of network tools that rely on it to execute scripts, from telnet and secure shell (SSH) sessions to Web requests.

According to several security firms, attackers are already probing systems for the weakness, and that at least two computer worms are actively exploiting the flaw to install malware. Jamie Blasco, labs director at AlienVault, has been running a honeypot on the vulnerability since yesterday to emulate a vulnerable system.

“With the honeypot, we found several machines trying to exploit the Bash vulnerability,” Blasco said. “The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system. This malware turns the systems into bots that connect to a C&C server where the attackers can send commands, and we have seen the main purpose of the bots is to perform distributed denial of service attacks.”

The vulnerability does not impact Microsoft Windows users, but there are patches available for Linux and Unix systems. In addition, Mac users are likely vulnerable, although there is no official patch for this flaw from Apple yet. I’ll update this post if we see any patches from Apple.

The U.S.-CERT’s advisory includes a simple command line script that Mac users can run to test for the vulnerability. To check your system from a command line, type or cut and paste this text:

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

If the system is vulnerable, the output will be:

vulnerable
 this is a test

An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

US-CERT has a list of operating systems that are vulnerable. Red Hat and several other Linux distributions have released fixes for the bug, but according to US-CERT the patch has an issue that prevents it from fully addressing the problem.

The Shellshock bug is being compared to Heartbleed because it affects so many systems; determining which are vulnerable and developing and deploying fixes to them is likely to take time. However, unlike Heartbleed, which only allows attackers to read sensitive information from vulnerable Web servers, Shellshock potentially lets attackers take control over exposed systems.

“This is going to be one that’s with us for a long time, because it’s going to be in a lot of embedded systems that won’t get updated for a long time,” said Nicholas Weaver, a researcher at the International Computer Science Institute (ICSI) and at the University of California, Berkeley. “The target computer has to be accessible, but there are a lot of ways that this turns accessibility into full local code execution. For example, one could easily write a scanner that would basically scan every Web site on the planet for vulnerable (Web) pages.”

Stay tuned. This one could get interesting very soon.

[dlevere]

ShellShock - Yet Another Code Injection Vulnerability

Written by Mike James

A vulnerability in the Bash shell has the Internet in full alarmed mode and like all good security holes it even has a catchy name - Shell Shock. How does it work?

Commentators are calling it either the most important security hole since Heartbleed or more damaging than Heartbleed. If you are holding your breath for something really subtle and complicated, breath again. It is a glaring and very obvious code injection vulnerability of the sort we have been warning SQL users about since almost before SQL was invented.

Bash, and most nix shells, are closer to macro processors than static languages, but don't let that lead you into believing that they aren't powerful.

In this case the problem comes about because Bash uses environment variables to pass functions that are exported so that child processes can use them. Normally environment variables store simple data such as a string specifying the current working directory. Some applications make use of environment variables to pass data to Bash scripts and to other programs. For example, CGI stores the HTTP headers as environment variables.

That is, environment variables are used to pass data between applications and the fact that an environment variable can also hold code should now be causing a red light to flash, because if you can pass in data and/or code this is a potential code injection hole.

So for example in the Bash shell you could define a function:

myFun () { echo "a function";}

and you could call the function by writing:

myFun

which would produce the text:

a function

The problem is that when you define a function Bash has no way of working out when the string that defines the function has completed its task - so it interprets the string to the very end.

For example, if you append a command to the end of the function it will be obeyed when the function is defined:

myFun() { echo "a function";};echo vulnerable

this prints

vulnerable

and the function is also defined.

This seems like a harmles quirk, until you remember that functions can be exported as environment variables for use by child shells. In this case it becomes very apparent that this is a way of executing a command in the child shell.

First we need to export a variable set to the string that represents the function with the additional command payload tagged on to the end.

export myFun=() { echo "a function";};echo vulnerable'

Now myFun exists as a string in the environment as you can prove using:

echo myFun

which displays the string.

If you now start a child shell that executes the function it inherits via the environment:

bash -c myFun

you will see

vulnerable
a function

What is happening here is subtle. The "vulnerable" is displayed when the function is defined and the "a function" when the function is invoked. This is why the two strings are displayed in the wrong order.

Now we come to the final part of the jigsaw. When you start a child shell all environment functions are defined, even if they are not used. That is, if you try:

bash -c "echo hello world"

you will see

vulnerable
hello world

That is, the payload has been executed even though the function was not called by the child shell.

What this means is that you can create a new environement variable that stores a function, i.e. an environement function with any name you care to pick, and the extra payload will be executed, even though the child shell doesn't call this new function.

That is, you have implemented a code injection.

Given that HTTP CGI, OpenSSH and other applications communicate with shell scripts etc via environment variables, you can see that it is possible to inject code during a standard transaction.

For example, an HTTP header like:

http-header[Host] = () { :; }; echo vulnerable

would cause the payload, in this case the echo, when any shell that inherited the environment was loaded.

How serious is the problem?

As always, it is difficult to say because any security hole is capable of being widened given time.

As it stands the payload runs at the security level of the process which is unlikely to have root privileges. This should limit the damage unless a way to elevate the payload's status can be implemented.

There have been reports of exploits being found in the wild, but as yet not much definite information exists.

Given the simple fact that any Linux website that uses any sort of CGI script hosted by Bash is vulnerable to the attack this is a problem that needs attention immediately.

A patch for Bash has been issued, but there seem to be some problems remaining after the patch has been applied.

It seems crazy that at this late stage, the Bash shell isn't new software, we are still falling victim to code injection. Using the same transport mechanism, i.e. environment variables for both external data and internal code, is the real cause of the problem. It seems likely that a solution can be found by restricting the form of environment functions so that no additional payload can be attached, but the real solution is to find another mechanism for sharing code between shell instances.

More Information

CVE-2014-6271: remote code execution through bash

CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

Related Articles

Heartbleed - The Programmer's View

The True Cost Of Bugs - Bitcoin Errors

GOTCHA - No More Password Hacking

Stick Figure Guide To AES Encryption

Android Security Hole More Stupid Error Than Defect

Is Exploiting A Bug Hacking?

Smartphone Apps Track Users Even When Off

Crypto Made Easy