Shellshock is bad, unique passwords are good

A new security bug, commonly known as Shellshock (Officially CVE-2014-6271, is bad. It is fair to say that a large number of servers (particularly web servers) were vulnerable to serious attack for some time. It is likely that many still are, and we are unlikely to learn about most of them.

What are we do to? Answer: Use unique passwords for each site and service.

Squirrels, rabbits, and passwords

Let’s consider Molly, one of my dogs. She has a one track mind: Squirrels and rabbits. She also is not very good at counting, so she doesn’t understand the difference between one track and two tracks.

Molly tends to reuse the same password for lots of things. Her password for Barkbook is squirrel. It’s also the password for CatChasers and a number of other sites and services.

Suppose that Patty, my other dog, isn’t the sweet innocent little thing that she pretends to be. Suppose that she breaks into CatChasers and is able to steal user passwords from it. She learns that Molly’s password was “squirrel” on CatChasers, so she’ll check if Molly used the same password on Barkbook and other sites.

Password reuse is doubly bad

Indeed, when Molly uses the password “squirrel” on multiple sites, she is putting all those squirrels in one basket. If her password is stolen on any one of those sites, Patty can get into all of those.

The more places that Molly uses the password “squirrel,” the more likely it is that at least one of that sites will get breached, and the more damage is done when her password gets discovered at any one of those sites.

If Molly uses “squirrel” for twenty sites, there is a very strong chance that several of them are vulnerable to this new Shellshock flaw, Heartbleed, or any of the other known and unknown vulnerabilities being exploited. When Patty does break into one of those twenty sites, she will now have control of twenty of Molly’s accounts.

What you can do

In short, be careful. System administrators will be busy for a while. In addition to upgrading bash on systems that use it, they should be trying to track down which systems create environment variables with untrusted content and whether those systems ever invoke a shell.

But normal people (and I don’t think that many will dispute that system administrators are not “normal people”) are left with the knowledge that there are a lot of vulnerable systems out there. By far, the single best things we can do is to cut down on our password reuse. The easiest way to do that with 1Password is to give Security Audit a whirl.

There is so much more to say

Everyone with some sort of security point to make is using Shellshock to help illustrate and draw their favorite lesson from it. This is easy to do because Shellshock isn’t just a bug, it is a bug that can be exploited because of a series of design decisions that were pretty much asking for trouble. Each one of those decisions (or non-decisions) is something that everyone in the business really does know better about. But somehow, the software and systems engineering community has managed to ignore its own wisdom at each step of the way.

1. We members of this community know not to pass untrusted data to various other processes, yet we’ve allowed systems that create shell environment variables (things designed to be passed all over the place) from the most untrusted sources of all. [E.g. CGI, DHCP Clients, etc].
2. Our community knows that tricking systems into executing “data” is often how attacks happen, yet bash has a feature that deliberately allows what is normally data passed around to be executed.
3. Whether computer science students like it or not they are taught that when data is in a particular class of languages it is impossible to validate it, yet with bash we’ve stuck a Type 0 languages inside of variables.
4. Scripts and programs should (generally) avoid invoking a shell as even the Linux manual page for system(3) says

Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be used to subvert system integrity.

Yet calling system(3) is common practice because it is easier than invoking other programs the proper way.

When a system falls victim to Shellshock, it is because every one of those principles and guidelines have been ignored. The first one is in the design of various network services (such as web servers). Numbers two and three are in the design of bash, and number four crops up in innumerable scripts and programs. None of them are actually about the specific bug in bash. Instead, one through three are about specific design features of various systems.

There is a great deal I would like to say about each of these, but I will leave that ranting for another time. Today, I just wish to remind everyone about the importance of using unique passwords for each and every service.

Bash update for Mac OS X

Apple has made bash updates available to those who do not wish to wait for regular software update:

OS X bash Update 1.0 may be obtained from the following webpages:
https://support.apple.com/kb/DL1767 – OS X Lion
https://support.apple.com/kb/DL1768 – OS X Mountain Lion
https://support.apple.com/kb/DL1769 – OS X MavericksTo check that bash has been updated:* Open Terminal
* Execute this command:
bash --version
* The version after applying this update will be:
OS X Mavericks:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
OS X Mountain Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12)
OS X Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11)

Jeffrey Goldberg

Principal Security Architect