Reacting to Shellshock

The code security industry is reeling from news that a flaw in the widely-used GNU Bash shell, dubbed Shellshock, could enable attackers to hack into vulnerable systems around the world. There have already been reports of exploits seen live and industry experts are both trying to combat the problem and quantify its impact. It already has four entries in the US National Vulnerability Database, covering similar flaws found after the original one, CVE-2014-6271.

Interpreting Bash

While Bash (Bourne-again shell) has been adopted and installed on many computers for over twenty years, it’s not surprising that the problem wasn’t discovered sooner – it’s the result of a type of security flaw called command injection in a fairly obscure feature of Bash command processing. Here’s an example of the exploit in action:

Here, the env command is setting an environment variable COLOR that contains an empty function () { :;}; and a command to open a second Bash shell to print out the string “I hate colors” using echo. If Bash were working properly, “vulnerable” wouldn’t get printed out as it’s buried inside the COLOR environment variable that’s never used. Since Bash is flawed, it treats the string after the function, echo vulnerable, as a real command and executes it.

Not a big deal in this example but if an attacker were to run a malicious command instead, bad things could happen. Since Bash can also be used to invoke other programs, an attacker can remotely impact unprotected systems anywhere.

Preventing the problem

This flaw falls under the Common Weakness Enumeration (CWE) type CWE-78, or “Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’).” This category covers flaws that are the result of improper or incorrect neutralization of elements that could modify an intended operating system command, as we saw above.

While the industry is scrambling to understand and fix the problem in the wild, it’s good to know that these types of flaws are easily detectable by static code analysis. In the case of Klocwork, these flaws are detected by three checkers as the developer is writing the code:

NNTS.TAINTED – finds code that uses string manipulation functions with character arrays that may not be null terminated, resulting in potential buffer overflows and security problems

SV.CODE_INJECTION.SHELL_EXEC – finds code that accepts command lines that are influenced by external input, resulting in the execution of potentially malicious commands

SV.TAINTED.INJECTION – finds code that doesn’t validate input from the user or outside environment, potentially resulting in the execution of arbitrary commands, unexpected values, or altered control flow

In our next article, we’ll take a look at an actual example of this and see how Klocwork reports the flaw. Can you guess which of the above checkers finds problems related to environment commands?