Re: [9fans] shell functions

[Russ Cox <rsc@swtch.com>]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2158 bytes --]