Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 11:50:35 +0200
From: Sven Kieske <>
To: <>
Subject: Re: Healing the bash fork

On 30/09/14 11:12, Mark R Bannister wrote:
> In fact, it only guarantees isolation from the Apache web server attack
> vector, but provides no guarantees from anything else we have not yet
> discovered that accepts arbitrarily named environment vairiables
> (I wonder what CVE-2014-6278 is all about, no technical details made
public yet ...).

Well Mr. Wheeler wrote:

On 29/09/14 20:50, David A. Wheeler wrote:
> I agree. If an adversary can arbitrary control the environment, it
> is definitely game over.
> What's more, this has been true for decades and this is *clearly*
> documented all over the place.
> If some program allows an untrusted user to control the content in
> arbitrary environment variables,
> that would be a security vulnerability in that other program, not in
> bash.

While I somehow agree with the above (this sure is a vuln in 3rd party
programs) I also still think bash should fix this by making it harder
to pass malicious content (e.g. switch an option like "yes-I-know-this
is-totally-insecure" to "on" ), even if it breaks
"backward-compatibility" and "workflows".

This reminds me of this:

bottom line: "Every change breaks someones workflow" - so this is no
excuse at all.

After all we're in the 21st century and programs need to become more
secure by orders of magnitude, compared to bad practices in the past.

This is a simple tradeoff:
making people fix their programs by a backward incompatible change
(in a new release) or allowing insecure stuff (just big projects
with security in mind will change their program)

as always: not to upgrade/ not to change things is no option at all

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.