Date: Tue, 30 Sep 2014 11:50:35 +0200 From: Sven Kieske <s.kieske@...twald.de> To: <oss-security@...ts.openwall.com> 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: https://xkcd.com/1172/ 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 Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de 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.