What Is Shellshock, How Does It Work and Why Does It Matter?

Image: Mashable, Bob Al-Greene

And we thought Heartbleed was bad. Welcome to Shellshock, the latest security threat to hit the Internet. And it's a doozy.

Like Heartbleed, Shellshock's technical complexity (when compared to other types of system vulnerabilities) makes explaining what the vulnerability is, how it works, and the potential damage challenging.

Talking about Bash commands and code injections and environment-variable definitions will make many eyes glaze over. And that's a bad thing, because Shellshock is serious. Very serious.

Software architect and Microsoft MVP Troy Hunt wrote a fantastic Shellshock FAQ that we highly recommend reading. Hunt does a good job of explaining what is what in English.

Here's what Shellshock means for you, the average user.

Let's Bash

If we distill Shellshock into the simplest terms, it's a vulnerability in Bash - system software used by millions upon millions of computers that opens up the possibility that an attacker could execute arbitrary commands on any machine running it.

Bash has been around since the late 1980s and is the default shell for OS X, Linux and some versions of Unix. By default, Windows machines and Windows servers don't run Bash, but versions of Bash are often installed on Windows. (This will be important later.)

Bash isn't just a command interpreter - it can also be used as a parser for CGI scripts - the way many websites display dynamic content. This is important because CGI scripts are often executed on Apache, the most common kind of web server in the world.

As you may remember from Heartbleed, about 50% of web servers run Apache, which means they may have some version of Bash on them. And that's without even taking into account any other web servers that might also have Bash installed as part of their setup.

Some users are getting confused in thinking Bash is the command line. It's not, but it is the most common command interpreter in the world and is installed on millions of systems.

One of the core functions of Bash is that it lets users define functions as a way to pass text onto other systems and processes. Usually, this is just fine - and hey, it's convenient, that's why it exists.

What's the problem?

The problem is that there is a major vulnerability that occurs when specific characters are included as part of a variable definition.

If the characters '{ :;};' are included as the function definition, any arbitrary code that is inserted AFTER that definition is processed. This isn't supposed to happen.

In other words, if I'm able to define what looks like a normal function with those special characters and then I tack on a few shell commands at the end of that definition, Bash will wind up executing those commands.

This is what is known as code injection - and it's a common type of attack.

The problem is exacerbated because lots and lots of utilities, particularly CGI and Apache, have access to Bash and can use it in the background.

This means a vulnerable server doesn't even need to have a user specifically type the injected code into the command line; someone can craft a script that will use the Bash command line to be able to execute code.

As Troy Hunt says in his FAQ, the potential for 'getting shell' on a box is enormous. Getting access to the command line is what hackers always want to do because it can give them access to an entire environment. That way, they can publish their own malicious code, start accessing internal data, reconfigure environments for their own use cases and more.

We want to be clear - getting shell isn't the same as getting root - but it does mean that it gives intruders a chance to play for bigger prizes in the bonus round. This could lead to privilege escalation to root via some other vulnerability you could find. And if you've got root - well, game over. The system is pwned.

Where Shellshock becomes really bad is if it's turned into a worm. A worm is a self-replicating attack where the malicious program creates code that launches itself on other targets which then launch themselves on other targets and so on. If you remember the Sasser worm or Samy the MySpace worm, you'll recall just how quickly this sort of thing can spread.

That's why for the last 36 hours or so, system administrators around the globe have been busy trying to patch their systems as fast as possible.

What versions of Bash are affected?

Ready for some bad news? It looks like basically every version of Bash through version 4.3 is affected by this vulnerability. That's 25 years worth of Bash installs.

Keep in mind, Bash often gets installed with other programs - so even Windows machines, which don't include Bash by default, could be vulnerable.

For now, the biggest target is web servers - and with half the Internet at risk, that's a big target area.

Regular users are probably safe, for now

So what about regular consumers? This is where it gets tough. If you run Windows and have never installed Git or Cygwin or other programs, you're probably OK - but you still want to stay abreast of any security updates.

Linux users can check with their distro for updates to patch Bash.

As for OS X, if you're familiar with the command line and compiling your own shell, you can update to a safe version, but we don't recommend you do that unless you really know what you're doing and are comfortable with the potential ramifications of an upgrade gone wrong.

The best bet is to wait for Apple to issue an update.

Right now, it doesn't look like anyone has come up with a way to execute code on individual machines (not servers), but the nature of this stuff does mean that it could become a worm targeting Mac systems.

The big-picture problem

The bigger concern, as with Heartbleed, is that there are tons of systems that might never get upgraded. With Heartbleed, we saw vulnerable versions of OpenSSL in lots of devices - including smartphones and routers - that will never get updated.

The potential for Shellshock is just as vast - if not more so, given the ubiquity of Bash.

The only silver lining is that Busybox, the operating system that most embedded systems use, has its own shell and doesn't rely on Bash.

Still, it's too early to know how bad this is or how far it could spread. The bigger companies and web servers are already patched. Now, it's time for the long tail of updates, and the longer systems remain unpatched, the more time attackers will have to use this vulnerability to craft some really nasty stuff.

We don't want to be alarmist, but this isn't good. And now it's more important than ever that system admins update their systems as soon as possible.

Have something to add to this story? Share it in the comments.