|
In October 2001, we discussed a security bug policy for mozilla.org,
which resulted in the
current policy. I was quite unhappy about the policy, with the
worst problems listed in the attached post. I also included Mitch's
reply. However, the policy very much reflected Netscape's interestes, probably because Netscape was such a big contributor back then and Netscape employed the security module owner. As I understood from later private comments, I wasn't alone in my opinion even within mozilla.org, and definitely not at large, although I was pretty much alone in the public discussion. The secrecy with which we deal with bugs may have supported Linux distributors and other vendors in being incredibly careless about updating the browser (Debian stable still ships Mozilla 1.0.0 (!!!) with more holes than swiss cheese stolen by a bunch of mice). There's also been public punishment for that, see attached mail. The policy isn't working. Some problems and facts:
So, given that Netscape is no more, can we use full disclosure now? In case that isn't being accepted and partially in addition to that, I propose the following changes to the policy and procedure:
I would probably volunteer for response and release teams. [1] <http://www.beonex.com/communicator/version/0.8/add-ons/security/png-2002-08-11.html> <http://www.beonex.com/communicator/version/0.8/add-ons/binaries/flash/> * There's a small problem: I don't know how to determine, which patches are already installed, without exposing patch status to attacker sites ------ Mail to security-group: -- <http://translate.google.com/translate?hl=en&sl=de&u=http://www.heise.de/newsticker/meldung/45443> <http://translate.google.com/translate?hl=en&sl=de&u=http://cert.uni-stuttgart.de/ticker/article.php?mid=1183> The RUS-CERT at Germany University Stuttgart released an Advisory, warning that Bugs in Mozilla are being fixed silently, without warning users apart from a useless "Several security-related bugs were fixed in 1.6". Linux distributors don't update their packages, leaving users exposed. Quote heise: "... comes to a destroying judgement about the security of the Open-Source browser" then quoting the advisory: "At the moment, Mozilla is at least in security questions obviously no convincing altlernative to the market leader." which was later being updated with: "We merely wanted to point out that Mozilla isn't a solution either for the security problems by which currently all clients are pleagued" A forum post (in response to the heise story) told that the background to the advisory is appearantly a recent debate on the open Debian security mailing list that Debian stable still ships 1.0.0 (as I pointed out before). |
--- Begin Message --- Thanks to Frank and Mitch to finally open up the security bugs a bit more. It is certainly a big improvement over the current scheme, which didn't work at all. Also many thanks for seriously considering my complaints about the policy and adjusting it in some places.
Nevertheless, the fact remains that the policy is far from my point of view on this matter. I'll summarize here, for the record. The main remaining problems are:
* It is not garanteed that users will be warned about all severe security bugs. In particular, there are classes of bugs which Mitch said he would not even want a warning about. (A "warning" here is a vage, public discription of the bug (without reproduction info), which allows users to judge their risk and take counter-measures.) * It is unclear, how much freedom distributors have while forwarding mozilla.org's warnings (those that *are* issued) to their users. * There is no garantee that bugs will be fixed timely. My approach would have been to force the disclosure of unfixed bugs after a certain time (e.g. 2 weeks) after reporting, with exceptions, if it was not realistically possible to fix the bug during that time. * The time between a bug being fixed and fully disclosed might be regularily very long (half a year or more).
Although I am not comfortable with the policy, I will participate in the security bug group, if allowed to, because I have not much to lose* by doing so and more to gain.
If my time and energy permits, I will try to act as a connection between the security-conscious people not in the security bug group and the group and to act as a voice for openness within the group. However, my time and enery is limited, so please to not rely on me.
I invite everyone seriously interested in security to apply as member in the security bug group and help fix and evalute the bugs and to make a case for openness.
Ben
--- End Message ---
--- Begin Message --- Ben,
Thanks for your input and for agreeing to participate. Believe me when I say we did take your comments seriously. Let me sum up my responses to some of your points, for the record.
* It is not garanteed that users will be warned about all severe security bugs. In particular, there are classes of bugs which Mitch said he would not even want a warning abou
(A "warning" here is a vage, public discription of the bug (without reproduction info), which allows users to judge their risk and take counter-measures.)
I'm afraid we're going to have to agree to disagree on this point for now. Let's see what happens with the current policy for a few months. If I'm not getting pressure from Netscape to release less information, then maybe we can move towards more warnings. No promises though. Loyalty to our respective organizations aside, I honestly think that releaseing even a vague warning for every single bug that goes into the security group, even if there's no workaround, even if the bug isn't exploitable on its own, is not in the best interests of the vast majority of our users. That's my story and I'm stickin' to it.
We should at least agree that any disclosure by one distributor or security group member is the same as disclosure by all. Your earlier comments support this.
* It is unclear, how much freedom distributors have while forwarding mozilla.org's warnings (those that *are* issued) to their users.
My apologies - I thought that point was clear. You can use the warning posted to www.mozilla.org/projects/security/known-vulnerabilities.html. You can change the wording as you see fit, but you can't add any information. Again, disclosure by one is disclosure by all.
* There is no garantee that bugs will be fixed timely. My approach would have been to force the disclosure of unfixed bugs after a certain time (e.g. 2 weeks) after reporting, with exceptions, if it was not realistically possible to fix the bug during that time.
There is no guarantee that any bug will be fixed timely, period. Any fixed time limits are simply not reflective of reality. The beauty of open source is that you don't have to wait for Netscape to fix a bug - if that bug is important enough to you, you can fix it yourself or pay someone to fix it, in two weeks or two hours.
You might as well drop this point because it's completely unrealistic and we will never agree to it.
* The time between a bug being fixed and fully disclosed might be regularily very long (half a year or more).
As you said to me on the phone, if we set an arbitrary time limit of one year, someone will come along and say "well, why not six months?" "why not one month?" It's a slippery slope. A fixed and arbitrary time limit is simply not necessary. Bugs will be opened to the public in a time frame that you and I both consider reasonable. As module owner I will see to that.
If my time and energy permits, I will try to act as a connection between the security-conscious people not in the security bug group and the group
Just make sure your 'connection' doesn't violate any confidentiality. When in doubt, ask the group first or ask that these "security-conscious people" be added to the group.
I invite everyone seriously interested in security to apply as member in the security bug group and help fix and evalute the bugs
I second that. -Mitch
--- End Message ---
