On Fri, Sep 26, 2014 at 12:32 PM, Kurt H Maier <khm@sciops.net> wrote:

Quoting Russ Cox <rsc@swtch.com>:

The right fix is to eliminate all possible interaction between (1) and (2).
The first public fix focused instead on making (1) more robust, and guess
what, it wasn't good enough and now there is a *second* CVE about this
problem, and a *second* attempt at making (1) more robust. It is almost
certainly too late to change CGI, but bash could be changed to just ignore
CGI's variables (HTTP_*), and I hope that's what will eventually happen.
I'm not holding my breath: I bet we'll see a cascade of patches trying to
make this interaction "safe" instead of removing it.

This is a heartbreakingly web-centric view of these issues. The real
problem is that bash was evaling stuff that had () { in it, and it is
very, very much not relegated to CGI use. There are exploits in the
wild for both DHCP and ssh.

Obviously bash is an awful shell, but munging it for apache is not the
right answer to anything.

That's fine. An even better change would be to make bash use a common but unlikely prefix for its function environment variables, like rc does. For example, if bash wrote the definition of function foo under the environment variable FN#foo instead of foo, it would naturally avoid the HTTP_* variables as well as any other variables being set with a common prefix by other servers. Same end result: bash's function parser no longer needs to be trusted to deal with hostile inputs.

Russ