Shellshock – CVEs, Patches, Updates, & Other Resources

First announced almost a month ago, Shellshock continues to endanger un-patched web servers and Linux devices. So what is it? How can you tell if you’re vulnerable? And how can it be addressed?

## What Is Shellshock?

Shellshock is a vulnerability in the `bash` software program. Bash is a shell, installed to Linux and other operating systems in the Unix family. A shell is a software component that is deeply integrated into the operating system, which is what makes this vulnerability so insidious.

The Shellshock vulnerability is a bug in the parser. It was first introduced more than 20 years ago when a feature to allow exporting functions was added. The danger is that an attacker who could control the _content_ of an environment variable could potentially execute arbitrary code on a vulnerable system. Remote code execution (RCE) vulnerabilities (also called “arbitrary code execution” vulnerabilities) are among the most dangerous. Paired with privilege escalation vulnerabilities or poor security practices (e.g. allowing web servers to run as privileged users), unaddressed arbitrary code execution vulnerabilities can lead to the complete takeover of vulnerable systems.

An unfortunately large number of arbitrary code execution vulnerabilities exist in modern software, most of them caused by bugs in code dealing with memory management. (As an aside, this is one reason many systems programmers are excited by new languages like Rust that provide more safety for memory management.) Bugs with memory management (like stack overflows, underflows, or poor bounds-checking) can be exploited by skilled attackers, but aren’t usually trivially exploited by code this trivial:

`env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”`

That’s the proof of concept for **CVE-2014-6271**, the initial Shellshock vulnerability. It fits in a blog post, and with a bit of experience writing shell scripts, it’s easy to see how it operates and how `echo vulnerable` could be replaced by a malicious payload. In other words, it’s easily exploited by a large number of potential attackers, even those with few resources at their disposal. The ease with which it can be exploited, combined with the fact that it allows for arbitrary code execution, the pervasiveness of bash on modern Unix systems means that Shellshock is a Very Big Deal.

Find more information here:

  • [RedHat’s FAQ](
  • [Updates on RedHat’s blog](
  • [“Quick notes about the bash bug, its impact, and the fixes so far”]( by Michał Zalewski
  • [“Everything you need to know about the Shellshock Bash bug”]( by Troy Hunt
  • David A. Wheeler’s _extremely detailed_ [Shellshock Timeline](

Checking for Shellshock

Use the bashcheck test script on GitHub.

### Known Shellshock Vectors

Shellshocker – a Repository of “Shellshock” Proof of Concept Code

Shell Shock Exploitation Vectors by Daniel Fox Franke

## Bugs (CVEs)

There are currently four published CVEs for recently discovered bash vulnerabilities. There are also currently two still embargoed CVEs.

  • CVE-2014-6271 – Original bug reported by Stephané Chazelas.
  • CVE-2014-7169 – “Incomplete fix for CVE-2014-6271” PoC by Tavis Ormandy (@taviso); posted to Twitter.
  • CVE-2014-7186From RedHat: “It was discovered that the fixed-sized redir_stack could be forced to overflow in the Bash parser, resulting in memory corruption, and possibly leading to arbitrary code execution when evaluating untrusted input that would not otherwise be run as code.”
  • CVE-2014-7187 – “An off-by-one error was discovered in the way Bash was handling deeply nested flow control constructs. Depending on the layout of the .bss segment, this could allow arbitrary execution of code that would not otherwise be executed by Bash.”
  • CVE-2014-6277Reported by Michal Zalewski (lcamtuf) of Google. The prefix-suffix patch does not fix this underlying issue, but reportedly makes it inaccessible to a remote attacker.
  • CVE-2014-6278 – “Sixth bug” reportedly very easy to exploit if only the first CVE-2014-6271 patch is applied. Reported by Michal Zalewski (lcamtuf) of Google. The prefix-suffix patch does not fix this underlying issue, but reportedly makes it inaccessible to a remote attacker.

## Shellshock Source Patches

### Official – “Upstream” / Chet Ramey

Available from the GNU Project Archive for 2.05b through 4.3 (3.2 and 4.3 patches called out below).

### Other – Vendors, 3rd-party (an incomplete list)

  • “Florian’s prefix-suffix patch”
    • Accepted upstream as bash32-054, bash43-027, etc.
    • The upstream version may have compatibility issues that still need to be resolved.
  • “Christos’ patch”
    • Disable feature except with flag, breaks backwards compatibility.
    • Adopted by both FreeBSD and NetBSD.
  • RedHat patch for CVE-2014-7186 & CVE-2014-7187

## Vendor Updates

### Ubuntu

– [USN-2362-1](
– [USN-2363-1](
– [USN-2363-2](
– [USN-2364-1](
– [USN-2380-1](

### CentOS (RedHat)

– [CESA-2014:1293 (RHSA-2014:1293-1)]( ([ELS: RHSA-2014:1294-1](
– [CESA-2014:1306 (RHSA-2014:1306-1)]( ([ELS: RHSA-2014:1311-1](

### Debian

– [DSA 3032-1](
– [DSA-3035-1](
– 4.2+dfsg-0.1+deb7u3 [patches](

Apple product security was [notified]( of the issue by Chet Ramey days in advance of the CVE-2014-6271 public disclosure. This issued a [“safe by default” Statement](

With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.

Manually applying patches to Bash for OS X – Apple posts source code for open source software they distribute. You can apply official upstream patches to this source. Here is one guide for this approach.

### Other Vendor Identifiers

## Other Shellshock Mitigations

### Firewall Signature Block

One approach to mitigating the issue is to block/drop all traffic that contains the exploit signature '() {', e.g.

iptables -A INPUT -m string --algo bm --hex-string '|28 29 20 7B|' -j DROP

But RedHat [notes]( that this “is a weak workaround, as an attacker could easily send one or two characters per packet, which would avoid matching this signature check. It may, in conjunction with logging, provide an overview of automated attempts at exploiting this vulnerability.”

There are several other OS-specific mitigation techniques listed on [that page](, too.

### Binary Patching(?!)

As a really hacky way to patch for CVE-2014-6271, it may be possible to edit the /bin/bash binary directly to break function importing and prevent the feature from being exploited. (For example: An interesting approach, at least.

## Prevention

The best way to prevent a vulnerability like this from being exploited on your systems is to enable [automatic security updates](