Shellshocked

26 September 2014
So it looks like the world's non-technical media have started crapping themselves over the latest software exploit, Shellshock. Of course a lot of people at least recall some of the problems caused by Heartbleed, and Shellshock has a lot of the attributes that also made the former a major headache. However, I don't consider Shellshock to be anywhere near as bad.

Background

Unix (including Linux & FreeBSD) has lots of command-line programs that do only one thing, so there is a culture of getting things done by stringing a load of them together using shell scripts. Writing of shell scripts is not much different to manual running of commands within a shell (command-line interface), but unlike MS-DOS era Batch files (autoexec.bat et al), shell script feature-lists are not that far off what one would expect from a fully-blown programming language. As a result, even non-scripting programming languages have features that allow call-outs to a shell for the odd task here or there. A lot of Linux-based user interfaces are simply front-ends to command-line utilities.

The Shellshock bug affects Bash, but on most modern Unix systems (especially Linux), Bash is by far the most commonly used shell. This ubiquitous use of Bash is one of the reasons why, like Heartbleed, Shellshock is considered a major exploit. It is also an exploit that is believed to have lain undiscovered since 2005, a time-frame that in computing is normally considered close to eternity.

Why I'm not worried

Exploitability of the bug is predicated on remote users being able to send requests that somehow end up being passed to Bash, which is increasingly rare these days. In the past entire dynamic web-sites were implemented as shell scripts using CGI, but these days passing anything that originates from a remote user to a shell is considered risky. A typical example is a photogallery package that uses ImageMagick for image resizing & format conversion.

Any package that provides a vector for Shellshock to be exploitable is one that does not properly sanitise input to shell commands, in which case there is a whole host of other tricks beside Shellshock that can be used to do dodgy things. As a result I would consider such security holes to be a flaws in the packages themselves rather than Bash. Some of the Apache webserver modules are apparently vulnerable, but I ditched that last year. Mindful of the damage Heartbleed did to OpenSSL's reputation, OpenSSH has been flagged as vulnerable to the exploit. However this requires users to be logged in first, and in most scenarios it does not let them do anything they could not do legitimately.