Shellshock is underplayed

The shellshock bug, though it’s now old news, is a bit more serious than how we treat it.

The best part? As best as the maintainer (I bet he’s getting a lot of email) can tell, this vulnerability has been around since 1992. This means that every version of bash I’ve ever used has been vulnerable to this, until last week, when I got the patch.

I’m an avid reader of Hacker News, and in today’s daily there’s an article about the bug. The author, Jonathan D. Hall, discusses methods of locating and testing servers for this vulnerability; specifically, he finds Yahoo and WinZip vulnerable, which is a serious problem in both cases (Yahoo because of the data they have, and WinZip because their software has an automatic updating feature).

If you’re more technically minded, I highly recommend that article. Jonathan makes some strong points and details some rather scary vulnerabilities.

The vulnerability

First, a bit on how it works. A bash function definition is terminated with a semicolon:

x={ :;};

This function x doesn’t do anything. But a vulnerable shell will continue interpreting after the function definition:

x={ :;}; echo vulnerable

This means that the first chunk of code (up until the second semicolon) will be considered the definition of the environment variable. After that, the code is interpreted as is.

To check, we can spawn a new shell in a new environment, defining that variable:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Vulnerable shells will print ‘vulnerable’.

Note that this is only for the first exploit. Several other related exploits have been found; please check yourselves if you or your servers run bash.

The exploits

Jonathan details the exploit he used, which involved sending bogus HTTP headers to certain web servers which produced the requisite environment variables. There are several other attack vectors detailed in the Wikipedia article:

OpenSSH and qmail both can be attacked remotely. A malicious DHCP server can be configured to send commands to clients.

Conclusion

Check any instance of bash for each exploit; there’s quick tests out there. Reboot your servers after you install the new version, so that you don’t have daemons running on the old one. And do it quick - Jonathan’s article makes it clear that this exploit is being used.