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: Mon, 29 Sep 2014 11:30:28 -0400 Message-ID: Subject: Re: [9fans] shell functions From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1143acf650d795050435f29b Topicbox-Message-UUID: 17ef1dd6-ead9-11e9-9d60-3106f5b1d025 --001a1143acf650d795050435f29b Content-Type: text/plain; charset=UTF-8 On Fri, Sep 26, 2014 at 12:32 PM, 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. That's fine. An even better change would be to make bash use a common but unlikely prefix for its function environment variables, like rc does. For example, if bash wrote the definition of function foo under the environment variable FN#foo instead of foo, it would naturally avoid the HTTP_* variables as well as any other variables being set with a common prefix by other servers. Same end result: bash's function parser no longer needs to be trusted to deal with hostile inputs. Russ --001a1143acf650d795050435f29b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 26, 2014 at 12:32 PM, Kurt H Maier <khm@sciops.net> wro= te:
Quoting Russ Cox <= ;rsc@swtch.com>:<= br>
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.

That's fine. = An even better change would be to make bash use a common but unlikely prefi= x for its function environment variables, like rc does. For example, if bas= h wrote the definition of function foo under the environment variable FN#fo= o instead of foo, it would naturally avoid the HTTP_* variables as well as = any other variables being set with a common prefix by other servers. Same e= nd result: bash's function parser no longer needs to be trusted to deal= with hostile inputs.

Russ
--001a1143acf650d795050435f29b--