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--