Handling Mozilla security bugs, draft 8 ("release candidate")
Frank Hecker
Mozilla security bugs, based on Mitch Stoltz's draft from 10/8 posted to
n.p.m.security (which was in turn based on my previous drafts).
The changes in this draft include:
* Clarifying that the security module owner (working with the peers and
other members of the security bug group), not the bug reporter, is
responsible for driving the process of investigating and disclosing
security bug reports. (A bug reporter would still have the power to
disclose bug reports originally submitted by them; they're just not the
primary person held responsible for getting the bug disclosed at some
point.) This change was made to address the concern that bug reporters
might forget about security bugs they reported, with bug reports then
remaining undisclosed in Bugzilla indefinitely; the security module
owner will be held responsible for making sure this doesn't happen.
* Changing the email address of the security bug group mailing list, to
securit...@mozilla.org.
* Changing the email address to which security bugs are reported, to
secu...@mozilla.org.
* Adding the requirement that publicly released vulnerability reports
should be sent to a moderated mailing list (and/or newsgroup) in
addition to posting them to a web page. (The list/group should be
moderated to cut down on spam and spurious posts. One can also conceive
of these reports being digitally signed using OpenPGP or S/MIME, to
minimize the likelihood someone will try to forge one, but I'll leave
those sorts of implementation details to others.)
* Making it clear that any future proposed changes to the policies on
handling Mozilla security bugs will be discussed in Mozilla-related
public forums (e.g., n.p.m.security), not just among Mozilla staff and
the members of the security bug group.
* Removing a trailing space on one line (the text of which was otherwise
unchanged).
I will be the first to admit that this policy does not necessarily
command 100 per cent unanimous approval in all its details. However IMO
it is a suitable starting point for addressing these issues, and I would
like to see us try out this policy for a while (say, for a few months)
and see how well it works in practice before trying to revise it
further. Therefore I'm declaring this a "release candidate" for the
official mozilla.org policy, and after taking final comments for the
next 24 hours or so I will propose to mozilla.org staff that this go
into effect.
Frank
--
Frank Hecker
hec...@mozilla.org
Ben Bucksch
> The changes in this draft include:
The changes you made look fine. More important are the changes you did
*not* make.
All: I discussed a bit more with each of Mitch and Frank privately some
time ago. Unfortunately, both discussions stopped at some point. I hope,
they don't disagree with me discussing the 2 most important points here.
1. Vendor warnings wording/content
Frank suggested the following wording wrt. vulnerability warnings:
"Mozilla distributors who wish to inform their users of the existence of
a vulnerability may redistribute these [official] security warnings
verbatim or use them as a basis for warnings to their own users. However
Mozilla distributors and others should not publish information that
could be used to create exploits for the bug."
That (which is different from the wording in the latest draft) would
work for me, with one exception discussed next.
2. No warning at all
Mitch told me that he in fact sees cases where a severe exploit would
not be warned about at all. He mentioned the case, where the only
workaround would be to stop using the product.
I do think that it is important to warn users even in those cases. If
Netscape doesn't want to issue a warning to its users, that's Netscape's
choice, but I would surely want to warn Beonex users. Under the current
policy, I would not be allowed to.
Even if the strategy Mitch proposed might sound reasonable /from a
certain point of view/, it is very problematic in practice. When exactly
is there "no workaround"? For example,
* does disabling JavaScript count as workaround? I would surely say
yes, and it would probably be the most common workaround, but
somebody could argue that many websites are not usable at all
without JavaScript. If we follow that argumentation, we wouldn't
warn about the majority of severe bugs.
* If there is a buffer overflow bug in the image lib, does it count
as workaround to disable images?
* If there is a overflow in HTTP, HTML or (mail-)MIME code, does it
count as workaround to use a filtering proxy? Many companies force
the use of a proxy anyway and could, maybe even without too much
hassle, install a proxy [rule], which protects against the
exploit. So, I would say that there is a workaround. Netscape OTOH
might argue that most of its users are individuals which are
connected directly to the internet and that it is (in fact)
unreasonable to ask them to install a proxy.
I stick to my point that it is necessary to warn users about every
severe bug. Every policy which disallows that does IMO put users
unnecessarily at risk.