Explaining the Shell Shock bug to a seven year old

The National Vulnerability Database rates the Shell Shock bug a 10 out of 10 in three categories:

  • Base
  • Impact
  • Exploitability

But this isn’t Dancing with the Stars, and in this case, a 10 is a bad thing; in fact – an egregious thing that actually represents the highest severity according to the DHS National Cyber Security Division.

In this guide, I’m going to synthesize this often confusing bug down to its essence and try to make it so easy to understand that a seven year can grasp it.

Here we go!

The phrase, shell shock, finds its genesis from military combat.  It’s often characterized as an intense dissolution of moral strength as a result of feeling utterly helpless during battle.

It usually manifests itself after battle and can result in chronic depression, severe headaches or even amnesia.  It’s a pretty serious problem.

But my definition explains how shell shock pertinent to war not computers.  What exactly is the Shellshock computer bug?

Cracking open the shell

Think of a computer shell like your English teacher who translates what you say into something the computer a understand.

So for example, let’s say you want to play some games on Nickelodeon.com.  You need some way to tell the computer what you want to do.  So you type the command to open the webpage and your computer responds with something like this:

“Hey, I need to open nickelodeon.com”

It then solicits the help of a few of its friends (other programs) to open the webpage for you.

The shell is just a program that’s responsible for translating your language commands into something the computer understands.

The reason the computer bug is called Shell Shock is because it’s roughly tantamount to how the IT community felt after finding out about it.

Image credit stephane.chazelas.free.frOn the morning of September 12th, a French computer genius named Stephane Chazelas made an earth shattering discovery.

Chazelas found out that the shell used by over 70% of the worlds computers, called bash, is susceptible to being attacked and has actually been that way for the past 21 years.

The same day Chazelas made the discovery, he reported it to Chet Ramey who is the guy who maintains the Bash programming code. Ramey then secretly told a few trusted distributors about the problem who consequently, each scrambled to build a fix known as patch.

In a statement, Chazelas told Fairefax Media:

The realisation of the scale and impact of [it] and what I had in my hands was quite scary

The real problem is that really smart bad people can connect to computers running vulnerable versions of the bash shell and basically tell the machine to kill itself.

Someone could create and send a specially designed command to seriously harm the computer.  Older computers are at the greatest risk of being exploited.

But what’s the big deal?

So what can the bad guys really do with this Shell Shock bug?

Unfortunately, A lot.

Hackers could completely take control of the computer.  They could sieze control of web camera, steal anything they wanted from the hard drive or completely delete everything on the computer.

Instead of sending a command to the computer to open nickelodeon.com, the shell shock bug allows a bad guy to tell the computer to download a virus or restart itself.

The problem is that bash not only translates your commands but is itself a scripting language.  This means you can create little programming nuggets called functions to execute your commands.

For example, I can login to a Unix or Linux computer and type this:

$ nickAtNite(){ echo "Whats up!"; }

Then if I type nickAtNite it will print this to the screen:

Whats up!

Now that’s good and won’t really cause any harm.

But let’s say I want to run my little function as a new instance of the command shell.  For example, I can create a new version of the bash shell and attempt to run my nickAtNite function in that clone like this:

$ export -f nickAtNite
$ bash -c nickAtNite

In the first line, we’re exporting all the data the function will need to run in the new bash instance and then in the second command we’re launching the new instance and executing the function.

So what does this have to do with shell shock bug?

Well – computers have these things called Environment variables that can hold all kinds of useful stuff such as your default photo editing program or your local time and date information.

In the shell shock bug, an attacker can create a new environment variable with an empty function but then append that line with bad code.

Let me show you what I mean.  Remember what our function looked like:

$ nickAtNite(){ echo "Whats up!"; }

Notice:

  • There’s a name followed by parenthesis
  • An open brace
  • Some text enclosed in quotes
  • A semicolon and then
  • A closing brace.

But it doesn’t have to look like that.  I could make an empty function like this:

(){:;};

This is hard to see at first but it’s a valid function with an empty body.

The body is simply a colon which means nothing and a semi-colon which finishes the statement.  Then after the closing brace there’s another semi-colon telling bash that everything is done.

With shell shock, someone could create a new environment variable, assign an empty function it but then include some malicious code after that final semi-colon.

For example, we could do this:

env bad='(){ :;}; echo Bad stuff here' bash -c :

Here we are setting the environment variable named bad to an empty function.  But then we are adding on unexpected bad code after the function and are telling the computer to do this in a new bash instance before secretly exiting.

Notice that final colon after the -c.  We’re telling the computer to open a new bash instance but don’t do anything with it.  The result is the computer executes the Bad stuff in the code and then silently exits without a trace.


The severity of this threat is arguably greater than the Heartbleed vulnerability discovered in April, because Heartbleed only allowed an attacker to spy on you not take over the entire computer.

It’s also easier to execute this attack.

According to Dan Guido, the head honcho of a Cybersecurity firm called Trail of Bits:

The method of exploiting this issue is also far simpler [than Heartbleed]. You can just just cut and paste a line of code and get good results

So how do you fix it?

Well, right now – you can’t.

Although there are patches for the bug, they are incomplete and thus it’s still possible for the bad guys to destroy your computer.

Tavis Ormandy demonstrated this on Twitter

Tavis Ormandy's Bash Exploit

and the comments on Hackernews are bustling with everyone realizing that patch CVE-2014-7169 doesn’t completely fix the problem.

If you’re running a Windows computer you’re okay but most of the websites on the internet run Linux which have the vulnerable versions of the bash shell running.

We’ll just have to wait for a stronger patch to fix the problem.

In the meantime, hackers are already exploiting the bug (as @yinettesys candidly admitted on twitter the other day).

@yinettesys tweeting how his sensors are already being affected by the bug

In fact, according to Juha Saarinen of ITNews.com.au, an Australian business site, there is already a collection of zombie computers known as the wopbot botnet, that is actively searching the internet for vulnerable systems to attack.


This is serious stuff.

What do you think of this vulnerability?  Do you have any tips?  Please share your comments below.

Update: 11:21est

Macs run a variation of Linux; however, since advanced UNIX services are disabled by default, most Mac users don’t have to worry about the bug.  In a statement to CNET, Apple said:

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

About

Connect with Vonnie on Twitter

Posted in News Tagged with: , ,