[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMtMF0UGj5J6WQ7GAGB9uU9sje0wQMM=qQX8mt7sdnkdzhbJQ@mail.gmail.com>
Date: Mon, 29 Sep 2014 20:52:48 +0200
From: Bernhard Hermann <bernhard.hermann@...il.com>
To: oss-security@...ts.openwall.com
Cc: langsec-discuss@...l.langsec.org
Subject: Re: Fwd: Non-upstream patches for bash
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
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.
