Attached is a new draft I've done for the proposal on how to handle
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
security-gr...@mozilla.org.
* Changing the email address to which security bugs are reported, to
secur...@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
[
security-bugs-draft8.html 18K ]
Handling Mozilla Security Bugs
Version 1.0
DRAFT 8
October 25, 2001
Introduction
In order to improve the Mozilla project's approach to resolving
Mozilla security vulnerabilities, mozilla.org is creating more formal
arrangements for handling Mozilla security-related bugs. First,
mozilla.org is appointing a security module owner charged with primary
responsibility for coordinating the investigation and resolution of
reported Mozilla security vulnerabilities; the security module owner
will have one or more peers to assist in this task. At the same
time mozilla.org is also creating a larger "Mozilla security bug group"
by which Mozilla contributors and others can participate in addressing
security vulnerabilities in Mozilla. This document describes how this
new organizational structure will work, and how security-related
Mozilla bug reports will be handled.
Note that the focus of this new structure is restricted solely
to addressing actual security vulnerabilities arising from problems
in Mozilla code. This work is separate from the work of developers
adding new security features (cryptographically-based or otherwise)
to Mozilla, although obviously many of the same people will be involved
in both sets of activities.
Note also that the scheme described in this document will
completely replace the traditional practice of marking
security-related Mozilla bugs as "Netscape Confidential." The mozilla.org
Bugzilla system is being modified to remove the ability
to mark bugs as "Netscape Confidential," and to instead implement
the scheme described below.
Background
Security vulnerabilities are different from other bugs,
because their consequences are potentially so severe: users'
private information (including financial information) could be
exposed, users' data could be destroyed, and users' systems could
be used as platforms for attacks on other systems. Thus people have
strong feelings about how security-related bugs are handled, and in
particular about the degree to which information about such bugs
is publicly disclosed.
The Mozilla project is a public software development project,
and thus we have an inherent bias towards openness. In particular,
we understand and acknowledge the concerns of those who believe
that all information about security vulnerabilities should be
publicly disclosed as soon as it is known, so that users may take
immediate steps to protect themselves and so that problems can get
the maximum amount of developer attention and be fixed as
soon as possible.
At the same time the Mozilla project receives substantial
contributions of code and developer time from organizations
that use (or plan to use) Mozilla code in their own product
offerings. Some of these products may be used by large populations
of end users, many of whom may not often upgrade or check for
recent security fixes. We understand and acknowledge the concerns
of those who believe that too-hasty disclosure of exploit
details can provide a short-term advantage to potential attackers,
who can exploit a problem before most end users become aware of
its existence.
We believe that both sets of concerns are valid, and that both
are worth addressing as best we can. We have attempted to create
a compromise scheme for how the Mozilla project will handle
reports of security vulnerabilities. We believe that it is a
compromise that can be justified to those on both sides of the
question regarding disclosure.
General policies
mozilla.org has adopted the following general policies for
handling bug reports related to security vulnerabilities:
- Security bug reports can be treated as special and handled
differently than "normal" bugs. In particular, the mozilla.org
Bugzilla system will allow bug reports related to security
vulnerabilities to be marked as
"Security-Sensitive," and will have special access control features
specifically for use with such bug reports. However a security
bug can revert back to being a normal bug (by having the
"Security-Sensitive" flag removed), in which case the access control
restrictions will no longer be in effect.
- Full information about security bugs will be restricted to
a known group of people, using the Bugzilla access control
restrictions described above. However that group can and will be
expanded as necessary and appropriate.
- As noted above, information about security bugs can be held
confidential for some period of time; there is no pre-determined limit
on how long that time period might be. However this is offset by
the fact that the person reporting a bug has visibility into
the activities (if any) being taken to address the bug,
and has the power to open the bug report for public scrutiny.
The remaining sections of the document describe in more detail
how these general policies have been implemented in practice.
Organizational structure for handling security bugs
We are organizing the investigation and fixing of Mozilla security
vulnerabilities similar to the way Mozilla project activities are handled
in general: There will be a security module owner, a small core group of
active contributors who can act as peers to the module owner, a larger
group of less active participants, and other people who may become
involved from time to time. As with other parts of the Mozilla project,
participation in Mozilla security-related activities will be open to
both independent volunteers and to employees of the various
corporations and other organizations involved with Mozilla.
The Mozilla security module owner and peers
The Mozilla security module owner will be
Mitch Stoltz.
Mitch has been actively involved full-time in the area of
Mozilla security for quite some time now, in particular as the
primary developer responsible for the so-called
component
security features of Mozilla.
The Mozilla security module owner will have a similar level of power
and responsibility as other Mozilla module owners; also as with other
Mozilla module owners, mozilla.org staff will oversee the work of the
security module owner and select a new security module owner should that
ever be necessary for any reason.
The Mozilla security module owner will work with
mozilla.org staff to select one or more people to act as peers to
the security module owner in investigating and resolving security
vulnerabilities; the peers will share responsibility for overseeing
and coordinating any and all activities related to security bugs.
The Mozilla security bug group
The Mozilla security module owner and peers will form the core of
the Mozilla security bug group, and will select a number of other
people to round out the group's membership. Each and every member of
the Mozilla
security bug group will automatically have access to all Mozilla
bugs marked "Security-Sensitive." The members of the Mozilla security
bug group will be drawn primarily from the following groups:
- security developers (i.e., those whose bugs are often singled
out as security-relevant or who have security-relevant bugs
assigned to them), and security QA people who are the QA contacts
for those bugs;
- "exploit hunters" with a good track record of finding
significant Mozilla security vulnerabilities;
- representatives of the various companies and groups
actively distributing Mozilla-based products; and
- super-reviewers and drivers.
(The Bugzilla administrators will technically be in
the Mozilla security bug group as well, mainly because they already
have visibility into all Bugzilla data hosted through
mozilla.org.)
The Mozilla security bug group will have a private mailing list,
security-group@mozilla.org,
to which everyone in the security bug group will be subscribed. This
list will act as a forum for discussing group policy
and the addition of new members, as described below. In addition,
Mozilla.org will maintain a second well-known address,
security@mozilla.org, through which people not
on the security group can submit reports of security bugs. Mail
sent to this address will go to the security module owner and peers,
who will be responsible for posting the information received to
Bugzilla, and marking the bug as "Security-sensitive" if it is
warranted given the nature and severity of the bug and the risk of
potential exploits.
Other participants
Besides the permanent security bug group members described above,
there are two other categories of people who may participate in
security bug group activities and have access to otherwise-confidential
security bug reports:
- A person who reports a security bug will have continued
access to all Bugzilla activities associated with that bug,
even if the bug is marked "Security-Sensitive."
- Any other persons may be given access to a particular
security bug, by someone else (who does have access) adding them
to the CC list for that bug.
Thus someone reporting a security bug in essence becomes a
member of the overall group of people working to investigate and fix
that particular vulnerability, and anyone else may be easily invited
to assist as well if and when that makes sense.
Expanding the Mozilla security
...
read more »
[
security-bugs-draft7-draft8-diff.txt 7K ]
*** security-bugs-draft7.html Wed Oct 24 14:03:05 2001
--- security-bugs-draft8.html Thu Oct 25 15:35:57 2001
***************
*** 19,26 ****
<div class=version>
Version 1.0<br>
! DRAFT 7<br>
! October 8, 2001
</div>
--- 19,26 ----
<div class=version>
Version 1.0<br>
! DRAFT 8<br>
! October 25, 2001
</div>
***************
*** 99,105 ****
handling bug reports related to security vulnerabilities:</p>
<ul>
! <li>Security bug reports will be treated as special and handled
differently than "normal" bugs. In particular, the mozilla.org
Bugzilla system will allow bug reports related to security
vulnerabilities to be marked as
--- 99,105 ----
handling bug reports related to security vulnerabilities:</p>
<ul>
! <li>Security bug reports can be treated as special and handled
differently than "normal" bugs. In particular, the mozilla.org
Bugzilla system will allow bug reports related to security
vulnerabilities to be marked as
***************
*** 119,127 ****
on how long that time period might be. However this is offset by
the fact that the person reporting a bug has visibility into
the activities (if any) being taken to address the bug,
! has the primary responsibility for deciding when the bug
! report should be opened for public scrutiny, and has the power to
! do so.</li>
</ul>
<p>The remaining sections of the document describe in more detail
--- 119,125 ----
on how long that time period might be. However this is offset by
the fact that the person reporting a bug has visibility into
the activities (if any) being taken to address the bug,
! and has the power to open the bug report for public scrutiny.</li>
</ul>
<p>The remaining sections of the document describe in more detail
***************
*** 194,209 ****
mozilla.org.)</p>
<p>The Mozilla security bug group will have a private mailing list,
! security-bug-gr...@mozilla.org,
to which everyone in the security bug group will be subscribed. This
list will act as a forum for discussing group policy
and the addition of new members, as described below. In addition,
Mozilla.org will maintain a second well-known address,
! security-bug-repo...@mozilla.org, through which people not
on the security group can submit reports of security bugs. Mail
sent to this address will go to the security module owner and peers,
! who will be responsible for posting the information received to a
! security bug.</p>
<h3>Other participants</h3>
--- 192,209 ----
mozilla.org.)</p>
<p>The Mozilla security bug group will have a private mailing list,
! security-gr...@mozilla.org,
to which everyone in the security bug group will be subscribed. This
list will act as a forum for discussing group policy
and the addition of new members, as described below. In addition,
Mozilla.org will maintain a second well-known address,
! secur...@mozilla.org, through which people not
on the security group can submit reports of security bugs. Mail
sent to this address will go to the security module owner and peers,
! who will be responsible for posting the information received to
! Bugzilla, and marking the bug as "Security-sensitive" if it is
! warranted given the nature and severity of the bug and the risk of
! potential exploits.</p>
<h3>Other participants</h3>
***************
*** 322,328 ****
<p>When a bug is put into the security bug group, the
group members, bug reporter, and others associated with the bug
! will decide by consensus, either through comments on the bug
or the group mailing list, whether an immediate warning
to users is appropriate and how it should be worded. The goals
of this warning are:</p>
--- 322,328 ----
<p>When a bug is put into the security bug group, the
group members, bug reporter, and others associated with the bug
! will decide by consensus, either through comments on the bug
or the group mailing list, whether an immediate warning
to users is appropriate and how it should be worded. The goals
of this warning are:</p>
***************
*** 343,360 ****
a peer, or some other person they may designate will post this
message to the
<a href="http://www.mozilla.org/projects/security/KnownVulnerabilities.html">
! Known Vulnerabilities</a> page.
Mozilla distributors who wish to inform
their users of the existence of a vulnerability may repost any
information from the Known Vulnerabilities page
to their own websites, mailing lists, release notes, etc., but
should not disclose any additional information about the bug.</p>
! <p>The original reporter of a security bug has the primary
! responsibility for deciding when that bug will be made public;
disclosure is done by clearing the bug's "Security-Sensitive" flag,
after which the bug will revert to being an ordinary bug. We believe
! that investing this power and responsibility in the bug reporter simply
acknowledges reality:
Nothing prevents the person reporting a security bug from
publicizing information about the bug by posting it to channels
--- 343,364 ----
a peer, or some other person they may designate will post this
message to the
<a href="http://www.mozilla.org/projects/security/KnownVulnerabilities.html">
! Known Vulnerabilities</a> page
! (which will be the authoritative source for this information)
! and will also send a copy of this message to an appropriate moderated
! mailing list and/or newsgroup (e.g., netscape.public.mozilla.announce
! and/or some other newsgroup/list established specifically for this purpose).
Mozilla distributors who wish to inform
their users of the existence of a vulnerability may repost any
information from the Known Vulnerabilities page
to their own websites, mailing lists, release notes, etc., but
should not disclose any additional information about the bug.</p>
! <p>The original reporter of a security bug may decide when that bug
! report will be made public;
disclosure is done by clearing the bug's "Security-Sensitive" flag,
after which the bug will revert to being an ordinary bug. We believe
! that investing this power in the bug reporter simply
acknowledges reality:
Nothing prevents the person reporting a security bug from
publicizing information about the bug by posting it to channels
***************
*** 387,393 ****
distributors can still be informed and take appropriate action.)</li>
</ul>
! <p>If disputes arise about whether or when to disclose information
about a security bug, the security bug group will discuss the issue via
its mailing list and attempt to reach consensus. If
necessary mozilla.org staff will serve as the "court of last
--- 391,401 ----
distributors can still be informed and take appropriate action.)</li>
</ul>
! <p>The security module owner will be the primary person responsible for
! ensuring that security bug reports are investigated and publicly
! disclosed in a timely manner, and that such bug reports do not remain
! in the Bugzilla database uninvestigated and/or undisclosed.
! If disputes arise about whether or when to disclose information
about a security bug, the security bug group will discuss the issue via
its mailing list and attempt to reach consensus. If
necessary mozilla.org staff will serve as the "court of last
***************
*** 413,420 ****
<p>As with other Mozilla project issues, mozilla.org staff will have
the final authority to make changes to this policy, and will do so only
! after consulting with the various parties involved, in order to ensure
! that all views are taken into account.</p>
</body>
</html>
--- 421,429 ----
<p>As with other Mozilla project issues, mozilla.org staff will have
the final authority to make changes to this policy, and will do so only
! after consulting with the various parties involved and with the public
! Mozilla community, in order to ensure that all views are taken into
! account.</p>
</body>
</html>
