From mboxrd@z Thu Jan 1 00:00:00 1970 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-D2A0372F-6B4C-4AB2-8263-D7CD410D4C62 Content-Transfer-Encoding: 7bit Message-Id: <5D4212F2-54AB-4D74-A569-81FBC55EB993@bitblocks.com> From: Bakul Shah Date: Fri, 26 Sep 2014 09:48:14 -0700 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Cc: Scott Schwartz Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 17361f34-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-D2A0372F-6B4C-4AB2-8263-D7CD410D4C62 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable With manipulating a path you still need access to a writable filesystem to s= ubvert a child shell. That step is not necessary if you can pass functions i= n the environment.=20 > On Sep 26, 2014, at 8:54 AM, Russ Cox wrote: >=20 > +9fans, since a few people have asked >=20 >> On Thu, Sep 25, 2014 at 6:15 PM, Scott Schwartz wrote:= >> Reading about the latest bash bug, I tried this with rc. >> Is it a bug? Feature? Other? >>=20 >> bash$ env 'fn#foo'=3D'{true} >> date >> ' rc >> Thu Sep 25 15:07:16 PDT 2014 >> % whatis foo >> fn foo {true} >=20 > It can be all of the above. > =20 > The shell executes things. It's acting a little weird in that transcript, b= ut not terribly beyond its normal duties. The fundamental security hole in t= he bash/CGI case is a bad interaction between (1) bash stores executable thi= ngs in the environment, and (2) CGI stores arbitrary data supplied by untrus= ted users in the environment. That's clearly not going to end well. >=20 > 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 w= hat, it wasn't good enough and now there is a *second* CVE about this proble= m, and a *second* attempt at making (1) more robust. It is almost certainly t= oo late to change CGI, but bash could be changed to just ignore CGI's variab= les (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 interac= tion "safe" instead of removing it. >=20 > Thanks to name space hygiene on td's part, the rc function space and the C= GI variable space do not overlap, so rc already has no possible interaction w= ith CGI, which is as it should be. I don't think it is super important to tr= y to make rc defend against malicious environments, any more than it is to m= ake it somehow defend against malicious $paths. If those are security-releva= nt, you've already lost. >=20 > I don't intend to try to fix rc. I closed https://bitbucket.org/rsc/plan9p= ort/issue/187 yesterday. >=20 > Russ --Apple-Mail-D2A0372F-6B4C-4AB2-8263-D7CD410D4C62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
With manipulating a path you still nee= d 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 <= rsc@swtch.com> wrote:

+9fans, s= ince a few people have asked

On Thu, Sep 25, 2014 at 6:15 PM, Scott Schwartz <ses101@= gmail.com> wrote:
Reading about the latest ba= sh bug, I tried this with rc.
Is it a bug?  Feature?  Other?

bash$ env 'fn#foo'=3D'{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 fu= ndamental security hole in the bash/CGI case is a bad interaction between (1= ) bash stores executable things in the environment, and (2) CGI stores arbit= rary data supplied by untrusted users in the environment. That's clearly not= going to end well.

The right fix is to eliminate a= ll possible interaction between (1) and (2). The first public fix focused in= stead on making (1) more robust, and guess what, it wasn't good enough and n= ow there is a *second* CVE about this problem, and a *second* attempt at mak= ing (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 c= ascade 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 h= as 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 environmen= ts, any more than it is to make it somehow defend against malicious $paths. I= f those are security-relevant, you've already lost.

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

Russ
<= /div>
= --Apple-Mail-D2A0372F-6B4C-4AB2-8263-D7CD410D4C62--