+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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 26 Sep 2014 16:32:12 +0000 Message-ID: <20140926163212.Horde.kuocVrN6KLWBJ9UPAJ0X3Q1@ssl.eumx.net> From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 172a7698-ead9-11e9-9d60-3106f5b1d025 Quoting Russ Cox : > 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. > This is a heartbreakingly web-centric view of these issues. The real problem is that bash was evaling stuff that had () { in it, and it is very, very much not relegated to CGI use. There are exploits in the wild for both DHCP and ssh. Obviously bash is an awful shell, but munging it for apache is not the right answer to anything. khm From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20140926163212.Horde.kuocVrN6KLWBJ9UPAJ0X3Q1@ssl.eumx.net> References: <20140926163212.Horde.kuocVrN6KLWBJ9UPAJ0X3Q1@ssl.eumx.net> Date: Fri, 26 Sep 2014 09:44:49 -0700 Message-ID: From: Skip Tavakkolian To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e013a05deafa8960503faa24e Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 172ec428-ead9-11e9-9d60-3106f5b1d025 --089e013a05deafa8960503faa24e Content-Type: text/plain; charset=UTF-8 you misrepresent. rsc addressed the non-web-centric issue: > 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. On Fri, Sep 26, 2014 at 9:32 AM, Kurt H Maier wrote: > Quoting Russ Cox : > > 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. >> >> > This is a heartbreakingly web-centric view of these issues. The real > problem is that bash was evaling stuff that had () { in it, and it is > very, very much not relegated to CGI use. There are exploits in the > wild for both DHCP and ssh. > > Obviously bash is an awful shell, but munging it for apache is not the > right answer to anything. > > khm > > > > --089e013a05deafa8960503faa24e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

you misrepresent. rsc add= ressed the non-web-centric issue:

> I don't think it is super important to try to ma= ke 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.

On Fri, Sep 26, 2014 at= 9:32 AM, Kurt H Maier <khm@sciops.net> wrote:

Quoting Russ Cox <rsc@swtch.com>:

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<= br> 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<= br> CGI's variables (HTTP_*), and I hope that's what will eventually ha= ppen.
I'm not holding my breath: I bet we'll see a cascade of patches try= ing to
make this interaction "safe" instead of removing it.

This is a heartbreakingly web-centric view of these issues.=C2=A0 The real<= br> problem is that bash was evaling stuff that had () { in it, and it is
very, very much not relegated to CGI use.=C2=A0 There are exploits in the wild for both DHCP and ssh.

Obviously bash is an awful shell, but munging it for apache is not the
right answer to anything.
khm

--089e013a05deafa8960503faa24e-- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 26 Sep 2014 16:55:36 +0000 Message-ID: <20140926165536.Horde.zSt4YsUnGF67-VxTNhnw9A3@ssl.eumx.net> From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <20140926163212.Horde.kuocVrN6KLWBJ9UPAJ0X3Q1@ssl.eumx.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 173b3500-ead9-11e9-9d60-3106f5b1d025 Quoting Skip Tavakkolian : > you misrepresent. rsc addressed the non-web-centric issue: > >> 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 misrepresent nothing, since I'm talking about what needs fixing in bash. I agree that rc doesn't need any patching -- to subvert rc like this you need to be able to *name* the variables. The problem with bash is that it's not just HTTP_ variables, but ALL variables that contain () { in them *anywhere* get evaled in full. Russ is advocating patching one attack vector instead of fixing the actual problem, and I disagree about that being a good idea. khm From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net From: Christian Neukirchen Date: Sat, 27 Sep 2014 16:40:40 +0200 Message-ID: <8738bdw2hj.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain In-Reply-To: (Russ Cox's message of "Fri, 26 Sep 2014 11:54:46 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 174ce02a-ead9-11e9-9d60-3106f5b1d025 Russ Cox writes: > 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. The problem could be completely avoided if the '{}' were implicit, that is, store fn foo { echo bar } as fn#foo=echo bar (Also, I heard Research Unix v8 sh(1) stored functions in the environment as "foo(){ ... }", i.e. without =. So this never clashes with any variable. Not sure if that works portably enough for plan9port, though.) -- Christian Neukirchen http://chneukirchen.org From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: arisawa In-Reply-To: <8738bdw2hj.fsf@gmail.com> Date: Sun, 28 Sep 2014 16:00:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8738bdw2hj.fsf@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 175ebe80-ead9-11e9-9d60-3106f5b1d025 Hello, when rc is invoked, rc reconstructs shell variable and shell functions = using files in /env/. in case of shell functions, rc evaluates whole data in the file. this feature makes problem if the content is fn foo {=E2=80=A6}; maliciouscommand I think this problem must be fixed. Kenji Arisawa 2014/09/27 23:40=E3=80=81Christian Neukirchen = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > The problem could be completely avoided if the '{}' were implicit, = that > is, store=20 >=20 > fn foo { echo bar } >=20 > as >=20 > fn#foo=3Decho bar >=20 > (Also, I heard Research Unix v8 sh(1) stored functions in the = environment > as "foo(){ ... }", i.e. without =3D. So this never clashes with any > variable. Not sure if that works portably enough for plan9port, = though.) >=20 > --=20 > Christian Neukirchen = http://chneukirchen.org >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Sun, 28 Sep 2014 10:39:00 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 177202ce-ead9-11e9-9d60-3106f5b1d025 > when rc is invoked, rc reconstructs shell variable and shell functions = using files in /env/. > in case of shell functions, rc evaluates whole data in the file. > this feature makes problem if the content is > fn foo {=E2=80=A6}; maliciouscommand How would a malicious agent put something into /env? If it's possible, how is this different from putting something into $home/bin/rc or binding something into /rc/bin ? From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: arisawa In-Reply-To: Date: Mon, 29 Sep 2014 22:03:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 17770026-ead9-11e9-9d60-3106f5b1d025 Hi, Richard, Problems comes from careless CGI handling. keep the following result in mind=20 term% 'fn#foo'=3D'fn foo {echo yes}; echo no ' term% rc no term% today, we have a number of malicious request to our web server. assume a web server accept a request with a query query=3D'fn#foo=3Dfn%20foo%20{echo%20yes};%20echo%20no%0a=E2=80=99= if the query is processed as follows: (the explanation is only for demo) term% query=3D'fn#foo=3Dfn%20foo%20{echo%20yes};%20echo%20no%0a' term% echo $query fn#foo=3Dfn%20foo%20{echo%20yes};%20echo%20no%0a term% ifs=3D'=3D' a=3D`{echo -n $query} term% b=3D`{echo -n $a(2) | sed 's/%20/ /g; s/%0a/\n/g'} term% echo -n $b fn foo {echo yes}; echo no term% $a(1)=3D$b term% rc no term% we can avoid such attacks by putting a prefix (say =E2=80=98QS_' as = Pegasus does) at the last stage. QS_$a(1)=3D$b assume the input field is =E2=80=9Cname=E2=80=9D, then some people = believe $a(1) is =E2=80=9Cname=E2=80=9D, and may carelessly=20 execute for simplicity $a(1)=3D$b and such CGI will work for almost all cases (because they are not = malicious). even if extra command in fn foo {=E2=80=A6}; maliciouscommand is removed in starting rc, careless handling makes problem. however it is much different in dangerousness between some environment = variable are destroyed and arbitrary commands can be executed.=20 Kenji Arisawa 2014/09/28 18:39=E3=80=81Richard Miller <9fans@hamnavoe.com> = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >> when rc is invoked, rc reconstructs shell variable and shell = functions using files in /env/. >> in case of shell functions, rc evaluates whole data in the file. >> this feature makes problem if the content is >> fn foo {=E2=80=A6}; maliciouscommand >=20 > How would a malicious agent put something into /env? If it's = possible, > how is this different from putting something into $home/bin/rc or > binding something into /rc/bin ? >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

Date: Mon, 29 Sep 2014 14:20:46 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b33d90871bde30504342242 Subject: Re: [9fans] shell functions Topicbox-Message-UUID: 17e87490-ead9-11e9-9d60-3106f5b1d025 --047d7b33d90871bde30504342242 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 September 2014 14:03, arisawa wrote: > today, we have a number of malicious request to our web server. > assume a web server accept a request with a query > query=3D'fn#foo=3Dfn%20foo%20{echo%20yes};%20echo%20no%0a=E2=80= =99 > but why should a web server put arbitrary data from a remote user unrestrained into the environment? even if rc used a restricted parser, as it stands you could still write fn#cd=3Dfn%20cd%20{do_horrible_thing} and it would stand a good chance of doing the horrible thing if the web server runs a shell script that does a cd. really, as with Apache, the problem is the uncritical nature of the web server. it's probably reasonable to have rc use a parser that accepts only functions, but that's for precision, not to fix a security problem elsewhere. --047d7b33d90871bde30504342242 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 29 September 2014 14:03, arisawa <arisawa@ar.aichi-u.ac.jp&g= t; wrote:

today, we have a number of malicious req= uest to our web server.
assume a web server accept a request with a query
=C2=A0 =C2=A0 =C2=A0 =C2=A0 query=3D'fn#foo=3Dfn%20foo%20{echo%20yes};%= 20echo%20no%0a=E2=80=99

but why should a web se= rver put arbitrary data from a remote user unrestrained into the environmen= t?

even if rc used a restricted parser, as = it stands you could still write fn#cd=3Dfn%20cd%20{do_horrible_thing}

and it would stand a good chance of doing the ho= rrible thing if the web server runs a shell script that does a cd.

really, as wit= h Apache, the problem is the uncritical nature of the web server.