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 20:52:48 +0200
From: Bernhard Hermann <>
Subject: Re: Fwd: Non-upstream patches for bash

On 29 Sep 2014 08:40, "Sven Kieske" <> 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.

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.