[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 16:17:31 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
CC: chet.ramey@...e.edu
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
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
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.
