Update: ShellShock’s Long Tail in the Enterprise

The recently disclosed vulnerability in the Linux Bash function dubbed “ShellShock” is creating a firestorm of coverage – and rightly so. The 22 year-old security hole is remotely exploitable and affects Linux based web servers and an unknown number of other devices that might run on linux and contain vulnerable services.

However, unlike the recent “Heartbleed” OpenSSL vulnerability, identifying systems vulnerable to Shellshock won’t be easy.

Shellshocked first came to light on Wednesday, when Linux vendors including Red Hat began warning about the security hole. The vulnerability allows a malicious actor to take advantage of built in Bash functions, wrapping them in environmental variables and then appending malicious code to the end of function definitions within the variable.

In a blog post, Redhat said that any application that runs a shell script using Bash as the command interpreter, or that is hooked onto a shell is vulnerable to attack. Paul Venezia, writing over at InfoWorld, gives one example of a possible attack in which an HTTP header is configured to include such an environmental variable – such as a user agent string. By sending that to a vulnerable Linux web server that calls Bash directly or using a system call, the attacker can run the malicious code on the vulnerable system, he notes.

Read Security Ledger coverage of the Heartbleed vulnerability in OpenSSL here.

“The systems that are really vulnerable to this are Linux-based web servers that run scripts that involve Bash,” Ron Gula, the CEO of Tenable Networks told The Security Ledger.

Compared to the so-called “Heartbleed” vulnerability in OpenSSL, Bash is dangerous not just because it is widespread, but because it is also trivial to exploit – requiring no special knowledge (beyond some simple scripting). That wasn’t true of Heartbleed.

In the case of the “Shellshock” vulnerability, a successful attack would give the attacker the ability to run commands on the compromised system with the same permissions as the Web server process. That could enable them to spawn an interactive shell on the system and perform any of a number of damaging acts: uploading malicious files, etc.  As Venezia at Infoworld writes: “It’s not an immediate rooting, but it’s a very uncomfortable situation.”

For these reasons, and others, NIST, in issuing an alert, rated it “10 of 10” in severity.

As with Heartbleed, it is also true that identifying and patching all the systems that are susceptible to the Bash vulnerability will be a long and time consuming task.

Most vulnerable distributions have been patched – with Mac’s OS X a notable example. IT groups also spent much of Wednesday and Thursday identifying exposed and vulnerable systems and patching them. However, it will take longer to chase down all the systems exposed to the vulnerability, experts agree.

“It’s the 80/20 rule,” said Chris Wysopal, the CTO of the application security testing firm Veracode. “We probably got 80 percent of the exposed systems on the first day, but the 20% of systems that we haven’t reached may take weeks or months to patch.”

Gula of Tenable said that applying the patch to vulnerable Linux web servers is easy enough to do. Identifying and fixing applications that may be surreptitiously calling Bash is much harder.

“Its not like you can run a web application scan for scripts that run Bash,” he said. “So you have to test every script and try injection tests,” he said. Similarly: there’s a good chance for ‘false positives’ in any sweep: Linux servers may have an unpatched version of Bash, but may not be configured as web servers or other applications that make them vulnerable, he said.

Still: fixing the vulnerability is low-hanging fruit: a straight forward task that’s guaranteed to thwart at least the current round of attacks. Compared with the complexity of patching OpenSSL and reissuing keys, that’s light work.

Given that organizations can figure out which systems are vulnerable, the job of patching them and moving on is easy, he said.

“It’s so easy to fix, you should just do it,” Gula said.

The long term fix, however, involves a more thorough audit of an organization’s applications – especially legacy applications written more than five or 10 years ago – or longer, says Wysopal. Those are the most likely to remain vulnerable and to contain offending scripts or functions that invoke Bash.

More broadly, the ShellShock vulnerability should further undermine trust in the “thousand eyes” model of open source security and integrity and invigorate privately funded efforts to improve the integrity of open source components.