[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5429ADF1.2000800@edwardprevost.info>
Date: Mon, 29 Sep 2014 12:07:29 -0700
From: Ed Prevost <me@...ardprevost.info>
To: oss-security@...ts.openwall.com
Subject: Re: Fwd: Non-upstream patches for bash
On 9/29/2014 11:52 AM, Bernhard Hermann wrote:
> On 29 Sep 2014 08:40, "Sven Kieske" <s.kieske@...twald.de> wrote:
>> On 27/09/14 17:06, Solar Designer wrote:
>>> Of course, what input is trusted vs. not may be unclear. Apparently, 20
>>> years ago bash developers considered all env vars to be trusted input,
>>> regardless of the names, which is how we got here.
>> 'Input sanitization: “you can suppress ‘bad
>> stuff’ in input+output to make it safe”
>>
>> Reality: Halting problem. Deal with it.'
> This seems to me to be the good old CODE vs. DATA issue.
>
> IMHO, ENV vars are supposed to always be DATA, never CODE.
> If code is allowed, the parser might always fail. Judging by the recently
> dug up dirt, it most certainly will.
> Passing code as ENV is an ugly hack, probably born out of necessity arising
> when trying to implicitly propagate code, because no alernatives are
> apparent, are they?
>
> If it's done at all, it should at least be explicit.
>
> That's why I'm voting for having the *BSD approach in upstream: make the
> parsing of ENV vars optional, default OFF.
>
> br,
> Bernhard Hermann
>
+1 I find this akin to Eric Kobrin's recommendation "using a separate
store for functions"
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.
