+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