Re: CVE-2014-6271: remote code execution through bash

[John Haxby <john.haxby () oracle com>]

On 25/09/14 04:01, Chet Ramey wrote:
> On 9/24/14, 9:30 PM, Solar Designer wrote:
>
> > > > > > The bash patch seems incomplete to me, function parsing is still
> > > > > > brittle. e.g. $ env X='() { (a)=>\' sh -c "echo date"; cat echo

There seems to be a wider issue even when we have well-formed functions
coming in, for example,

    env rm='() { echo will not; }' bash -c 'rm core'

Well, that's OK, I thought, I'll just start my scripts with

   PATH=...
   unalias -a
   unset -f $(typeset -F)

or something like that.   But what if

   env unset='() { :; }' bash ...

unset does nothing now.

   command unset -f $(typeset -F)

countered with

   command='() { eval "$@"; }'

At some stage scripts are going to break, especially if they're relying
on command, but this whole exercise leaves me feeling uneasy.   ssh and
sudo both restrict environment variables, but I just tried this:

  $ xxx='() { echo hello; }' su
  Password:
  # xxx
  hello

Of course, su isn't affected, but if I drop one of these in for an
overly-trusting admin who runs su on my terminal ...


My feeling is that if you're going to import functions from the
environment then you should do that explicitly either through a switch
(--import?) or a builtin that can import all or selected functions.  Or
both.

I worry that simply fixing CVE-2014-6271 and CVE-2014-7129 is just
setting the scene for the next parser problem.

jch