Open Source

Bash shell vulnerabilities plague Linux systems, and may be more damaging than Heartbleed

An exploit discovered in bash that has existed for approximately 20 years is causing a mad dash by admins to patch affected systems. Here's a simple test to see if your install of bash is vulnerable.


A critical bug discovered in the ubiquitous Bash shell has become a major security risk to various Unix, Linux, and BSD systems — spanning web servers, desktop installations of Linux, Mac OS X, and integrated devices such as routers, among others.

In order to exploit the flaw, attackers must be able to send a malicious variable to a program implementing bash (or able to invoke a command in bash) that interacts with the network. For servers, legacy web applications that use CGI would be a possible exploit. Shortly after the disclosure of the exploit, a botnet was identified attacking Akamai servers, as well as a United States Department of Defense network.

How the bug works

The bug, discovered by Stephanie Chazelas, affects bash dating back to version 1.13 — over 20 years ago. According to the NIST vulnerability listing for the bug nicknamed "Shellshock" by Robert Graham of Errata Security, classified as CVE-2014-6271, authorization is not required to perform the exploit, and the issue is rated a 10 for exploitability. From NIST:

"GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution."

(Also see the description of the vulnerability on SecLists.Org. Thanks to Jack Wallen for the link.)

Although perhaps not the most easily exploited bug in the world on modern systems, many legacy programs still rely on CGI for functionality, and could be a potential vector for attack. Other devices, such as industrial control systems, are also likely vulnerable.

Why this is a problem

Jim Reavis of the Cloud Security Alliance, notes in a blog post that despite bash being a local shell, this is a major exploit:

A large number of programs on Linux and other UNIX systems use Bash to setup environmental variables which are then used while executing other programs. Examples of this include Web servers running CGI scripts and even email clients and web clients that pass files to external programs for display such as a video file or a sound file.

Reavis provides a simple test to identify if your installation of bash is vulnerable:

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

Affected systems will return "vulnerable", before the text "this is a test".

The potential damage for this bug is somewhat worse than the Heartbleed bug earlier this year — Heartbleed merely leaked information such as user passwords, but it did not allow malicious users to gain control of an affected system.

Patching this bug

The first patch to this issue is vulnerable to being crashed from a null-pointer exception; this bug is classified separately as CVE-2014-7169. A completed patch for this was made available by Red Hat early on September 26, 2014, with Fedora also issuing packages for the fix.

However, patching bash to fix this bug isn't quite as straightforward as patching OpenSSL to fix Heartbleed. With Shellshock, network-accessible embedded systems (such as printers or routers) might be using bash, and vendors may be sluggish to issue patches for these systems. Luckily, many newer embedded systems operating on Linux use the less resource-intensive busybox in favor of bash.

Mac OS X users must wait on Apple to issue a fix, though an involved fix can be applied until such a patch is released.

Alternative shells such as Dash are not affected by this issue.

What's your damage?

Are systems for which you are responsible affected by this exploit? For web servers, have you patched bash directly, or disabled CGI access to limit exposure? Is this exploit as concerning as the Heartbleed exploit from earlier this year? Let us know in the comments.

Also see

Note: TechRepublic, CNET, and ZDNet are CBS Interactive properties.

About James Sanders

James Sanders is a Java programmer specializing in software as a service and thin client design, and virtualizing legacy programs for modern hardware.

Editor's Picks

Free Newsletters, In your Inbox