On Fri, Sep 26, 2014 at 12:32 PM, Kurt H Maier <[email protected]> wrote:
> Quoting Russ Cox <[email protected]>: > > 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
