Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.