Re: shell functions

[Russ Cox <rsc@swtch.com>]

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

+9fans, since a few people have asked

On Thu, Sep 25, 2014 at 6:15 PM, Scott Schwartz <ses101@gmail.com> wrote:

> Reading about the latest bash bug, I tried this with rc.
> Is it a bug?  Feature?  Other?
>
> bash$ env 'fn#foo'='{true}
> date
> ' rc
> Thu Sep 25 15:07:16 PDT 2014
> % whatis foo
> fn foo {true}
>

It can be all of the above.

The shell executes things. It's acting a little weird in that transcript,
but not terribly beyond its normal duties. The fundamental security hole in
the bash/CGI case is a bad interaction between (1) bash stores executable
things in the environment, and (2) CGI stores arbitrary data supplied by
untrusted users in the environment. That's clearly not going to end well.

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.

Thanks to name space hygiene on td's part, the rc function space and the
CGI variable space do not overlap, so rc already has no possible
interaction with CGI, which is as it should be. I don't think it is super
important to try to make rc defend against malicious environments, any more
than it is to make it somehow defend against malicious $paths. If those are
security-relevant, you've already lost.

I don't intend to try to fix rc. I closed
https://bitbucket.org/rsc/plan9port/issue/187 yesterday.

Russ

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