Four no-bull facts about the Shellshock Bash bug

Get the scoop on the security threat billed as the biggest since Heartbleed

In barely the course of a day, word of the Shellshock exploit has reached Heartbleed-level proportions. But like any security hole du jour, it's easy to see only the hype and not the hard truth. Here are four of the most crucial details about Shellshock and its implications.

1. It's a security hole exploitable through software present in almost every Linux distribution...

Bash, the command shell used by many Linux distributions, has a bug that allows arbitrary commands to be executed by way of malformed environmental variables.

While Bash is nominally a console app, researchers have found that on some servers it's possible to invoke the bug by sending a specially crafted HTTP request. Robert Graham of Errata Security has demonstrated one example of this.

2. ...but it's not automatically exploitable

Hyperbole about Shellshock has already started running high. NIST rates the bug -- officially named "CVE-2014-6271" -- 10 out of 10 for its impact and exploitability. Microsoft MVP Troy Hunt calls it "potentially the easiest website defacement vector we’ve ever seen, not to mention a very easy way of distributing malware," as the ability to arbitrarily invoke the shell allows an immense number of other activities. Alleged sample exploits are already making the rounds.

That said, a system with Bash isn't always remotely exploitable. The key, as Graham noted, is when that resource "first sticks some Internet parameter in an environmental variable, and then executes a Bash script."

The situation is not commonplace or automatic. Jen Ellis of security firm Rapid7 notes that "modern Web frameworks are generally not going to be affected.... This bug is going to affect an unknowable number of products and systems, but the conditions to exploit it are fairly uncommon for remote exploitation."

What's most vulnerable? CGI scripts invoked from an HTTP request, as well as PHP applications running via CGI that can make calls to Bash. SSH servers are also vulnerable, but only from within authenticated sessions, according to Akamai's Andy Ellis, which makes them harder to exploit.

3. Comparisons to Heartbleed are tempting, but misleading

The severity of the issue isn't the only likely reason for the comparisons between Shellshock and Heartbleed -- the number of Linux systems running some version of Bash is also a factor. InfoWorld's Roger Grimes noted the difficulties in tracking down and patching all systems in a given organization that had a Heartbleed issue.

At first glance, Shellshock seems even worse. Rich Collier, Tech Lead at Moguldom Media Group, noted, "Heartbleed was a vulnerability in OpenSSL exclusively, and only machines running that software were vulnerable. While that was indeed a huge number of machines, Shellshock likely affects a much higher percentage of production servers on the Internet since Bash is running by default."

Ellis, however, doesn't believe that Shellshock is automatically worse because it's more widespread. For one, the immediately visible attack surface for Shellshock is comparatively smaller than Heartbleed's. Also, while embedded Linux devices seem like they would be a problem -- hard to detect, harder to fix -- Ellis was skeptical about their exposure.

For instance, devices that use Busybox -- a miniaturized collection of Unix utilities, including a shell -- aren't likely to be affected, since Busybox isn't known to use a vulnerable version of Bash.

"A quick review of a approximately 50 firmware images from a variety of enterprise, industrial, and consumer devices turned up no instances where Bash was included in the filesystem," Ellis wote. "By contrast, a cursory review of a handful of virtual appliances had a 100 percent hit rate, but the Web applications were not vulnerable due to how the Web server was configured."

4. Still, it should be found and fixed -- as soon as we can fix it

Admins can find out if a given system is vulnerable to Shellshock by running a short test at the command line. Mac OS X systems, as it turns out, are as vulnerable as many Linux systems.

Fixing the problem ought to be easy: Upgrade Bash to a patched version, as patches have been made available for versions of Bash from 3.0 through 4.3. Red Hat has started rolling out its patches, since RHEL going back to version 4 is vulnerable. Amazon Web Services also appears to be upgrading its machine images in a hurry.

Unfortunately, the fixes don't quite fix everything yet: It's still possible to craft exploits even with the patch in place. An entirely new NCAS vulnerability definition has been created to cover the minor issues that remain exposed, with a separate fix to be pushed out later. Red Hat's take is the first patch covers enough ground that it should be applied anyway, and customers shouldn't wait for follow-ups.

[Addendum: Amazon has since made a blog post stating that the EC2 maintenance updates were not related to Shellshock.]

Copyright © 2014 IDG Communications, Inc.