Is Shellshock a Feature, not a Bug?

The devastating Shellshock security flaw that was found in the open source Bourne Again Shell (Bash) UNIX shell highlights a major dilemma faced by all users of all software.

On the one hand, software that is tried, tested, proven and patched where necessary is likely to be more secure than a newly developed piece of software which has not been around long enough for the most serious bugs in it to be found. Security and leading edge software rarely go hand in hand.

But older software — especially software that predates the mass adoption of the Internet — may have been built without any notion of today’s security risks. That means they may include features which developers would never have built in if they could have foreseen today’s hostile computing environment.

While the Shellshock security flaw in Bash has been widely touted as a bug, it’s not clear that it is a bug at all. It’s more than likely that it is actually a feature that was built in to the software, never widely used or documented, and then forgotten.

How Shellshock Works

To summarize the flaw, Bash takes in a function definition and processes it; after it has done that, it will continue by executing any command that follows the definition. A quarter of a century ago that could have been a handy feature – define a function and then invoke it.

Critical instances where the vulnerability may be exposed include Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or that spawn Bash subshells, or on any system where the /bin/sh interface is implemented using Bash.

Back then the developer had no idea that Bash would end up on millions upon millions of machines around the world, and that these machines would be connected to the Internet – often running Web servers and welcoming incoming traffic. And that this Bash feature would allow malicious hackers to send malicious code to these machines, which they would then obligingly execute.

It gets even worse. Among many other capabilities, Bash has the ability to send and receive network traffic. Again, this was probably something that was quite useful many years ago if you wanted to connect to a remote machine for some reason.

Reverse Shell Game

If you are familiar with security/hacking tools like Metasploit, you’ll be aware of reverse shell programs. When executed on a system, a reverse shell program will connect out over the Internet to a pre-defined IP address and port. A utility such as Netcat at that IP address, listening on that port, will receive the connection and then start an interactive session with the remote system running the reverse shell program. And an interactive session gives the user command line control over that system — total compromise, in other words.

So all a malicious hacker has to do is send a suitably crafted request to a remote system running (for example) the Apache Web server and equipped with Bash (which just about every UNIX and Linux system does), to tell Bash to execute a reverse shell.

Since Bash has the ability to send and receive network traffic, then that’s trivial. The attacker can send a request to vast numbers of remote machines — each time specifying a different port to use — and then listen in on those ports and wait for the reverse shell interactive sessions to start.

Open Source Security Issue

Once again, this raises questions about the security of open source software, which is widely used. How did this flaw go undetected for so long when it is used with most mainstream open source operating systems, as well as numerous appliances?

(Of course, theories abound that certain agencies such as the NSA may have known about it for some time and actively exploited it.)

Open source software is “supposed” to be secure because the code is open to inspection and therefore flaws can be spotted, but clearly this isn’t occurring — not in this case, and not in the recent Heartbleed bug. Or at least, the flaws aren’t being spotted by the people who want to see them fixed.

This begs a question about whether security is best served by open source software, which is freely available and a de-facto standard. When a serious flaw is found, the consequences are felt on a global scale — especially if they are exploited using other open source software (like the Apache Web server) which is also a de-facto standard.

Perhaps the most important thing to say about this is that your security shouldn’t be compromised, even if you are vulnerable to Shellshock. That’s certainly the view of Anton Chuvakin, a research vice president at Gartner. “Do not make your security architecture solely reliant on patching,” he advises. “Big vulnerabilities will happen and so will zero-days, so make sure that your entire security architecture does not crumble if there is one critical vulnerability: Do defense in depth, layers, “least privilege,” controls not reliant on updates, monitoring, deception, etc.”

How to Fight Shellshock

What can you do to prevent being compromised by Shellshock?

Unusually, this is a security flaw that only affects open source based operating systems, so if you are only running Windows you don’t need to do anything. (But don’t forget that some of your appliances may be running Linux and Bash.)

The systems that are affected are:

  • GNU Bash through 4.3
  • Linux and Mac OS X systems, on which Bash is part of the base operating system
  • Any BSD or UNIX system on which GNU Bash has been installed as an add-on
  • Any UNIX-like operating system on which the /bin/sh interface is implemented as GNU Bash

You could of course stop using Bash, but it’s likely that doing so will break plenty of other applications. So the most important thing is to patch the utility as quickly as possible. According to US-Cert initial solutions for Shellshock do not completely resolve the vulnerability. It is advised to install existing patches and pay attention for updated patches to address CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 and CVE-2014-6278.

When it comes to other forms of protection, an application-aware firewall can help. That’s because it can analyze application data, and it won’t – for example – allow telnet traffic that a malicious hacker may be sending when they have a remote shell to go through an http port like port 80.

Standard firewall egress filters can help too. That’s because a reverse shell won’t work if the protocol and port combination that it is trying to use is closed. That’s a good reason to keep all outgoing ports closed unless they are specifically needed.

Finally, intrusion detection systems (IDS) may also help detect some malicious incoming Shellshock traffic, but it’s a fairly simple matter for malicious hackers to modify the content of their malicious code to avoid detection.

Ironically the most effective way to resolve the problem might be for someone to write a worm that hunts for vulnerable systems and then executes code which patches them automatically – but unfortunately that would be illegal.

Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.

Paul Rubens
Paul Rubens is a technology journalist based in England, and is an eSecurity Planet contributor.

Top Products

Related articles