9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Bakul Shah <bakul@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Cc: Scott Schwartz <ses101@gmail.com>
Subject: Re: [9fans] shell functions
Date: Fri, 26 Sep 2014 09:48:14 -0700	[thread overview]
Message-ID: <5D4212F2-54AB-4D74-A569-81FBC55EB993@bitblocks.com> (raw)
In-Reply-To: <CADSkJJWP=cdMxXFH_Oo04Cp2tTxfD6kTTeXx22N6BOBBmj3fLA@mail.gmail.com>

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

  parent reply	other threads:[~2014-09-26 16:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAL0h+tWUCrwWoTSeLz+Kx1yqKwKqwDBZZbH7fLe-PWXjLSgWWw@mail.gmail.com>
2014-09-26 15:54 ` Russ Cox
2014-09-26 16:32   ` [9fans] " Kurt H Maier
2014-09-26 16:44     ` Skip Tavakkolian
2014-09-26 16:55       ` Kurt H Maier
2014-09-29 15:30     ` Russ Cox
2014-09-26 16:48   ` Bakul Shah [this message]
2014-09-27 14:40   ` Christian Neukirchen
2014-09-28  7:00     ` arisawa
2014-09-28  9:39       ` Richard Miller
2014-09-29 13:03         ` arisawa
2014-09-29 13:20           ` Charles Forsyth
2014-10-01  9:37             ` arisawa
2014-09-29 18:05           ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5D4212F2-54AB-4D74-A569-81FBC55EB993@bitblocks.com \
    --to=bakul@bitblocks.com \
    --cc=9fans@9fans.net \
    --cc=ses101@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).