[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1XYg1P-0007bB-Jr@rmm6prod02.runbox.com>
Date: Mon, 29 Sep 2014 14:50:07 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
CC: "ekobrin" <ekobrin@...mai.com>,
"chet.ramey" <chet.ramey@...e.edu>,
"solar" <solar@...nwall.com>,
"lcamtuf" <lcamtuf@...edump.cx>,
"fweimer" <fweimer@...hat.com>
Subject: Re: Healing the bash fork
> On Sep 29, 2014, at 11:59 AM, Eric Blake <eblake@...hat.com> wrote:
>> But I see no reason to move away from %% suffixing.
On 29 September 2014 10:39, Kobrin, Eric <ekobrin@...mai.com> wrote:
> The suffix fixes the obvious CGI hole, but it leaves exposed programs in which the adversary gets to choose the variable name as well...
On Mon, 29 Sep 2014 10:49:22 -0700, Tavis Ormandy <taviso@...xchg8b.com> wrote:
> If an adversary can choose the variable name, it's game over by definition.
> He can choose LD_PRELOAD, SHELLOPTS='xtrace' PS4='$(foo)', ...
I agree. If an adversary can arbitrary control the environment, it is definitely game over.
What's more, this has been true for decades and this is *clearly* documented all over the place.
If some program allows an untrusted user to control the content in arbitrary environment variables,
that would be a security vulnerability in that other program, not in bash.
> This general solution is robust, now we're just hammering out the details.
I agree, Florian Weimer's approach does a *great* job of completely countering
the general attack path as currently understood.
I also like Chet Ramey's tweak that changes the suffix from "()" to "%%", that's a nice refinement
(the suffix no longer contains metacharacters).
That said, a lot of people are looking to find other attack paths. Shellshock has pointed out
a kind of attack path that most people hadn't examined before.
I'd still like to see Christos Zoulas's approach included eventually, since that's an even stronger
countermeasure. After all, if function imports only happen on request, then
non-requesters will have no problem. But I also understand that Zoulas's approach
is backwards-incompatible, and thus the bash folks are hesitant to apply it.
If that can't be added now, perhaps it could be added in a next release of bash?
--- David A. Wheeler
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.
