Bash To Require Further Patching, As More Shellshock Holes Found

Bismillah writes Google security researcher Michael 'lcamtuf' Zalewski says he's discovered a new remote code execution vulnerability in the Bash parser (CVE-2014-6278) that is essentially equivalent to the original Shellshock bug, and trival to exploit. "The first one likely permits remote code execution, but the attack would require a degree of expertise to carry out," Zalewski said. "The second one is essentially equivalent to the original flaw, trivially allowing remote code execution even on systems that deployed the fix for the initial bug," he added.

Comments

Nothing to do with language

[dutchwhizzman]

First of all, it's Bourne shellcode and bash has extensions to it. Second of all, whether the programming language is bad or not is totally not relevant. It's the parser in the shell itself that has some fundamental flaws because it executes code inside environment variables that are totally unchecked. You could have a brilliant programming language and still make the exact same mistake.

While you may say that is "by design" it is not common for Bourne shell to do so and most of shell scripts are written to be Bourne shell compatible. By choosing to allow this to happen, Bash programmers made a giant hole in shell security.

Re:Nothing to do with language

[K. S. Kyosuke]

The problem with bash is that even more than most shells (perhaps except for zsh), it's exceedingly obscure and baroque. This kind of featuritis, combined with the N^2 interaction between the individual features, tends to lead to unexpected consequences. What happened to "keep things simple" with shells?

Call it what you will

[benjymouse]

The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.

This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).

Re:Call it what you will

[c]

The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.

(you could say that there is a design vulnerability in CGI - and I would agree about that).

Debatable.

There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.

And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.

On the other hand, the environment is a perfectly stupid way to pass code around.

Re:Soon to be patched

[king neckbeard]

I think you'll find bone-headed obvious holes from time to time from almost all software vendors, with MS being no exception.

Re:Soon to be patched

[Dcnjoe60]

You thought you could run a totally free hobbyist OS and have it be as secure as one done by paid professionals?

Be glad its there for you to use at all. People donate their time and energy to it. Don't look a gift horse in the mouth.

Some would argue that Mac OS X isn't a totally free hobbyist OS and yet, with all of their paid professionals, they have yet to patch the bug. On the other hand, Linux being a free hobbyist OS means that researchers have the ability to scan the code and discover these types of holes. Something that is impossible for closed systems.

Re:not supposed to be on the web!

[Cid Highwind]

And it's the developers of all those packages and distros that symlink /bin/sh to bash instead of something minimal and well-audited that we should be screaming at. But "remote root exploit in bash" is sexier (after all, Apple doesn't put procmail on every Mac) so that's what goes in the headline.
 
...and next time someone goes on a rant about systemd versus "the Unix way", remember that daemons passing input from the network to /bin/sh is part of "the Unix way".