[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Sep 2014 21:21:40 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash
* Florian Weimer:
> Someone has posted large parts of the prenotification as a news
> article, so in the interest of full disclosure, here is what we wrote
> to the non-vendors (vendors also received patches):
Oh dear. It's now been implied that something leaked before the
embargo was over, or that more information was disclosed than planned.
This is not the case, on neither count. I was just annoyed that parts
of a private message I wrote ended up on a news site without my prior
consent. The disclosure as such wasn't a problem, except for a single
technical inaccuracy that has since been corrected. It was an honest
mistake, apologies were made and accepted. It did not impact the
disclosure schedule at all (it happened after the disclosure), nor the
amount of information being disclosed in any material way (the Red Hat
blog post contained essentially the same information). Once I saw
what happened, I decided to publish the full message here.
So to repeat: The embargo was scheduled for 14:00 UTC today, and my
initial brief posting was not prompted by a desire to withhold
information. I just wanted to limit the amount of possibly
conflicting technical information, and I had other duties to attend
to. (In retrospect, I should probably have included the message from
the prenotification from the start, which would have avoided any
confusion.)
We'll also want to discuss additional hardening measures (see my
message about BASH_FUNCDEFS), and we previously agreed to do this
publicly, after disclosure. Obviously, the technical details are
necessarily public once we do that.
It's often tricky to decide how much information to include in a
public vulnerability disclosure. In this particular case, I think we
had to publish technical details so that those who cannot patch
immediately can at least try to mitigate this vulnerability using
filters on devices in front of web servers, or tools like
mod_security. And without the technical details, I doubt this
vulnerability would have received the attention it deserves until
someone figures things out. We could easily have obfuscated the patch
to delay this, but what's the point?
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.
