Posted on Thu 25 September 2014

shellshock explanations

Today or tomorrow you’re going to start hearing about “ShellShock”, a vulnerability in approximately all UNIX, Linux, and Mac OS X systems, and probably a few Windows systems.

Is it a big deal? Yes, definitely.

edited later that day

Is it something that you can do anything about as an end user? A little, which you should do, but it won’t help much. (Apply security updates in the next few days; you should be doing this all the time, but even more so now.)

Should you worry about it beyond that? To the extent that you aren’t a sysadmin, no. To the extent that you’re my father, run:

sudo apt-get update
sudo apt-get upgrade

Now the technical part, which I will attempt to make both non-technical and mostly correct.

You know that UNIX people use command-line interfaces all the time. Those are the long lines of green text that hackers type in movies. Those are real, though most of the things that hackers do in movies with command lines can’t actually be done. Command-line interfaces are called shells, because they form a thin layer between your fingers and the important stuff underneath.

One of the most popular programs for managing those command-line interfaces is called bash, the Bourne-Again Shell. Yes, it’s a pun on the name of a previous version. bash has been in use for over 25 years, and people keep adding features to it and turning it into a complete programming environment (albeit a very primitive and generally uncomfortable programming environment).

It was recently discovered that an attacker can pass some specially formatted data to the bash shell which, wrongly, bash will decide is a valid command. Normally we wouldn’t worry very much about this, because you need to be an authorized user of a system before you get access to a bash command-line.

However, bash is very widely used as a sort of glue in between other programs; it’s very fast and easy to do that, and although “everyone knows” that you should replace it with a more permanent method, somehow that doesn’t happen until there’s a performance problem. Then you’ll often find that calling up bash isn’t very fast, just convenient. So lots of places in many systems just do the convenient thing. Web servers. Network tools. Infrastructure where it’s more important to get things working right now than anything else.

And as a result of that convenience, we now have methods for evil people to run code on our systems – mostly in places that we haven’t looked at in a long time.

Fixes were issued yesterday for many systems, and more will come in today, but it also looks like the first fix may not have been complete, and a second one is being tested.

EDIT: by 1900 Eastern, a second patch has been generally agreed on and released for general distribution. The problem now reduces to the all too familiar race of finding and patching computers that are running bash.

© -dsr-. Send feedback or comments via email — by continuing to use this site you agree to certain terms and conditions.

Built using Pelican. Derived from the svbhack theme by Giulio Fidente on github.