[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMtMF17RLOL9O=q2EUuPQBfO0vrS0kjuMMAs_BZx4VmOhM-yQ@mail.gmail.com>
Date: Fri, 26 Sep 2014 15:37:52 +0200
From: Bernhard Hermann <bernhard.hermann@...il.com>
To: oss-security@...ts.openwall.com
Cc: christos@...las.com, chet.ramey@...e.edu
Subject: Re: Re: CVE-2014-6271: remote code execution through
bash (3rd vulnerability)
On Sep 26, 2014 2:48 PM, "John Haxby" <john.haxby@...cle.com> wrote:
> Sufficiently unusual, I'd venture, that it should not be done
> implicitly. Florian's "BASH_FUNC_x()" makes it easier to blacklist
> these environment variables and ensures that a web server's HTTP_ prefix
> will not just create an oddly named function ... is that enough? Should
> bash simply make importing functions something that one has to ask for
> explicitly as Christos Zoulas (and others) suggested[1]?
I strongly believe that it should have been implemented this way from the
start.
Can anyone argument why making the import of functions explicit might be
unwanted in any use case?
Importing implicitly looks to me like buying powdered drugs from anonymous
shady street dealers - there's a slim chance you might get what you wanted,
but the odds (& esp. implications) of getting something toxic "from your
environment" are most probably higher.
best regards,
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.
