Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 16:17:31 +0100
From: John Haxby <>
Subject: Re: CVE-2014-6271: remote code execution through bash

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

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

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

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


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.