With manipulating a path you still need access to a writable filesystem to subvert a child shell. That step is not necessary if you can pass functions in the environment.
> On Sep 26, 2014, at 8:54 AM, Russ Cox <[email protected]> wrote: > > +9fans, since a few people have asked > >> On Thu, Sep 25, 2014 at 6:15 PM, Scott Schwartz <[email protected]> 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
