Re: shell functions

Re: shell functions

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

+9fans, 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?  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

[-- Attachment #2: Type: text/html, Size: 2520 bytes --]

Re: [9fans] shell functions

[Kurt H Maier]

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

Re: [9fans] shell functions

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2280 bytes --]

Re: [9fans] shell functions

[Kurt H Maier]

Quoting Skip Tavakkolian <skip.tavakkolian@gmail.com>:

> 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

Re: [9fans] shell functions

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

On Fri, Sep 26, 2014 at 12:32 PM, 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
>> 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

[-- Attachment #2: Type: text/html, Size: 2158 bytes --]

Re: [9fans] shell functions

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

With manipulating a path you still need 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, 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?  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

[-- Attachment #2: Type: text/html, Size: 2938 bytes --]

Re: [9fans] shell functions

[Christian Neukirchen]

Russ Cox <rsc@swtch.com> 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  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: [9fans] shell functions

[arisawa]

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 {…}; maliciouscommand
I think this problem must be fixed.

Kenji Arisawa

2014/09/27 23:40、Christian Neukirchen <chneukirchen@gmail.com> のメール：
> 
> 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  <chneukirchen@gmail.com>  http://chneukirchen.org
> 
> 

Re: [9fans] shell functions

[Richard Miller]

> 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 {…}; 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 ?

Re: [9fans] shell functions

[arisawa]

Hi, Richard,

Problems comes from careless CGI handling.

keep the following result in mind 
term% 'fn#foo'='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='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a’
if the query is processed as follows: (the explanation is only for demo)
term% query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a'
term% echo $query
fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a
term% ifs='=' a=`{echo -n $query}
term% b=`{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)=$b
term% rc
no
term%

we can avoid such attacks by putting a prefix (say ‘QS_' as Pegasus does) at the last stage.
	QS_$a(1)=$b

assume the input field is “name”, then some people believe $a(1) is “name”, and may carelessly 
execute for simplicity
	$a(1)=$b
and such CGI will work for almost all cases (because they are not malicious).

even if extra command in
	fn foo {…}; 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. 

Kenji Arisawa

2014/09/28 18:39、Richard Miller <9fans@hamnavoe.com> のメール：

>> 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 {…}; 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 ?
> 
> 

Re: [9fans] shell functions

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On 29 September 2014 14:03, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:

> today, we have a number of malicious request to our web server.
> assume a web server accept a request with a query
>         query='fn#foo=fn%20foo%20{echo%20yes};%20echo%20no%0a’
>

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=fn%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.

[-- Attachment #2: Type: text/html, Size: 1406 bytes --]

Re: [9fans] shell functions

[arisawa]

thanks for all.
our conclusion is: worthless to fix.

Kenji Arisawa

Re: [9fans] shell functions

[erik quanstrom]

> today, we have a number of malicious request to our web server.

i don't see any malicious requests that could possibly bother the standard release.
plan 9 is just too obscure to bother with.

- erik