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 08:39:59 +0200
From: Sven Kieske <>
To: <>
CC: <>
Subject: Re: Fwd: Non-upstream patches for bash

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.

Well, from a scientific point of view, this was already
solved, if I'm interpreting bash correctly.

See page 12 in this paper:

To quote for the lazy:

'Input sanitization: “you can suppress ‘bad
stuff’ in input+output to make it safe”

Reality: Halting problem. Deal with it.'

This should be true for all turing complete
input languages (which I assume bash is capable of).

So you can not "filter" turing complete input languages
unless you restrict your language so hard that you
in fact create another class of languages, e.g.
just allow regex, which would create a context-free
language[1], which would circumvent whole classes of exploits.

Also cc'ing langsec-list, as they are interested
in getting this stuff fixed in real applications.


Mit freundlichen Grüßen / Regards

Sven Kieske

Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

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.