From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 26 Sep 2014 11:54:46 -0400 Message-ID: Subject: Re: shell functions From: Russ Cox To: Scott Schwartz Cc: 9fans <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b343406afd3ee0503f9efb0 Topicbox-Message-UUID: 172683c6-ead9-11e9-9d60-3106f5b1d025 --047d7b343406afd3ee0503f9efb0 Content-Type: text/plain; charset=UTF-8 +9fans, since a few people have asked 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? > > 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 --047d7b343406afd3ee0503f9efb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+9fa= ns, 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?=C2=A0 Feature?=C2=A0 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 abov= e.
=C2=A0
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 be= tween (1) bash stores executable things in the environment, and (2) CGI sto= res 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 publi= c fix focused instead on making (1) more robust, and guess what, it wasn= 9;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 h= olding my breath: I bet we'll see a cascade of patches trying to make t= his 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 i= nteraction with CGI, which is as it should be. I don't think it is supe= r important to try to make rc defend against malicious environments, any mo= re 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/plan= 9port/issue/187 yesterday.

Russ
--047d7b343406afd3ee0503f9efb0--