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.