Share with your network!
Shellshock has been getting a lot of press as the worst security bug ever, but while it is terribly embarrassing for the open source movement, I believe the real world impact will be fairly limited. The bug is a fundamental flaw in bash, the command line interface on most Linux and Mac machines. (For once Windows users can relax. The Windows command line, a descendant of the original MS/DOS operating system, is not affected.) However, in order to exploit the bug, you have to already have some sort of access to that command line. In other words, the door to the safe has been left open, but a thief still had to get into your house to steal the cash.
The bash shell provides a large number of powerful and flexible utilities. When programming system software for Unix, it's common for some parts to be written as shell scripts, using these utilities rather than making calls to the operating system directly. If your computer has a program on it that is being accessed externally, it’s possible that a malicious attacker could construct a ‘bash injection attack’, similar to a SQL injection attack, in which malformed parameters get interpreted as commands. This is a big problem because bash is run in unexpected places, and this makes assessing the actual impact of shellshock difficult. You have to do a lot of digging to find all the places where bash is invoked with environment variables that might have come in from the network. It’s an old principle of security that privileged programs should be as simple as possible. Shells, designed to be flexible, customizable, and powerful, are very difficult to run securely with elevated privileges.
At Cloudmark, we see a lot of compromised web servers abused by spammers. Shellshock opens another avenue of exploitation for these machines. Simply serving web pages does not expose you, but there are a number of other things you could do, from post processing sever logs to using certain types of CGI script, that could open you up to this bug. Other sorts of custom services such as code repositories may also contain vulnerabilities. Indeed, vulnerabilities have even been found in some common mail server setups.
So web servers are not automatically vulnerable, but many of them are, and in potentially unexpected ways. Is this a huge problem? Not really - or at least, the status quo isn't much worse than before. If a system doesn't get patched for shellshock, it's almost certainly got many other vulnerabilities as well. This hole is just one of many.
[tweet_box]Every day we see hundreds, sometimes thousands, of newly compromised web servers used by spammers.[/tweet_box]
Every day we see hundreds, and sometimes thousands, of newly compromised web servers used by spammers. We recently reported on the claim that a group of hackers had compromised 420,000 web servers using SQL injecting attacks. I didn’t see a single follow up report showing that anyone had suffered any significant real world harm.
The vulnerable software is in a lot of places, so shellshock is going to suck up a lot of time as people focus on auditing and patching a succession of bugs in bash, but in a basic way it’s not something new. Remote execution exploits as a class are an old and understood problem. In comparison, Heartbleed was something new, a nearly-undetectable way for an adversary to steal credentials and subvert your encryption.
More web servers under the control of cybercriminals means more spam for Cloudmark to block, and increases the chance of a devastating DDoS attack. However, as the attack on Spamhaus showed, it does not take a huge number of compromised servers to launch a devastating attack if you use DNS amplification. A teenager in the UK managed to launch the Spamhaus attack with a handful of compromised servers and list of open DNS resolvers. The best way to stop this happening again is to improve DNS security across the Internet rather than try to secure every web server out there. The latter was a lost cause well before shellshock.
Mike Acar also contributed to this post