Shellshock: Every version of Linux stretching back over two decades is vulnerable

Last week on September 24, the details of a vulnerability in the widely used Bourne Again Shell (Bash) were disclosed by multiple Linux vendors. The vulnerability, assigned CVE-2014-6271 by Mitre, was originally discovered by Stephane Chazelas, a Unix and Linux network and telecom administrator and IT manager at UK robotics company SeeByte, Ltd.

While this vulnerability didn’t come with quite the fanfare or a catchy name like Heartbleed, the security community quickly dubbed it “Shellshock.” Bash is present in most Linux and Unix distributions as well as Apple’s Mac OS X, and there’s a good chance anyone reading this has a system they need to patch.

Palo Alto Networks initiated an emergency IPS content release to detect this vulnerability last night with Signature ID: 36729 “Bash Remote Code Execution Vulnerability.”

All versions of PAN-OS and Panorama include the vulnerable version of Bash, but we’ve determined the issue is only exploitable by authenticated users.

Vulnerability Details

CVE-2014-6271 exists in all versions of Bash and is related to how environment variables are processed when the shell starts up. Environment variables are used by shell software to store pieces of information like the location of the user’s home directory. In addition to storing variables, Bash allows for storing shell functions in variables that users can call later. It’s in parsing these functions that the new Bash vulnerability exists, as the shell mistakenly executes code that is added after a function definition.

Here’s an example: $ env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test” vulnerable this is a test

Bash should stop processing the environment variable “x” after the closing semicolon for the function, but instead continues to process “echo vulnerable”. At first glance, this might not seem too dangerous as executing commands is Bash’s primary function, but it’s important to understand that many other programs use Bash to process commands.

-- Apache Servers running mod_cgi and mod_cgid may spawn Bash shells and pass malicious HTTP Headers and request variables that exploit the vulnerability.
-- OpenSSH parses passed environment variables with Bash in some cases, making it vulnerable to privilege escalation through this vulnerability.
-- While these two scenarios are currently the most-likely vectors for exploiting this vulnerability, it’s likely that other services use Bash in a network-exploitable way. The only way to fully prevent exploitation is to upgrade Bash on the system to a non-vulnerable version.

Impact
The good news is that this vulnerability was disclosed responsibly and patches are available for most platforms on the day of the public disclosure. The bad news is that this vulnerability is going to have a very long tail. Bash is the default shell for the most-popular Linux variants and every version of the software stretching back over two decades is vulnerable. Well-maintained systems will be patched today, but that dusty old system in the networking closet might never get the update. Additionally, network devices, embedded systems and Internet-connected devices (like IP Cameras) often run Linux and could be vulnerable.

Fortunately, not every system is remotely exploitable simply because it’s running Bash, it also needs to be running an application which makes Bash accessible over the network. As described above, the most-common exploit scenario seems like it will be web servers running Apache and using CGI scripts. Web servers are great resources for attackers. They can be used to:

-- Launch DDoS attacks
-- Infect visitors with malware
-- Gain a foothold in a network and spread to additional systems
-- Steal sensitive data accessible to the web server

These are all likely outcomes from mass scanning of the Internet for vulnerable hosts, which are already underway.