[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6900DC89-C4A7-46EC-9F6C-FF03A426D610@akamai.com>
Date: Mon, 29 Sep 2014 17:06:00 -0500
From: "Kobrin, Eric" <ekobrin@...mai.com>
To: "dwheeler@...eeler.com" <dwheeler@...eeler.com>
CC: oss-security <oss-security@...ts.openwall.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 2:50 PM, "David A. Wheeler" <dwheeler@...eeler.com> wrote:
> 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.
It was also a flaw in the other program when the adversary was able to set the values. That flaw is so prevalent that we now have these recent patches.
My point is that we can tell the other people that they are using bash wrong, or we can take steps to make it harder to use unsafely. Introducing namespaces with prefixing and suffixing is fine for a quick patch, but I'd argue that it is too fragile for long term use.
What is the motivation to not store executable code (functions) differently from standard variables?
-- Eric Kobrin
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.
