In addition to the changes Frank requested, I've rewritten the section
about a 'known vulnerabilities' page on mozilla.org to clarify what it's
about, and I changed the section about mailing lists. As I discussed
with staff, we should have separate lists for discussion and outside bug
reports.
Please give me your comments on these changes. Bear in mind they were
made by me alone and are just a proposal - they are open to debate.
Also, please outline what issues still need to be discussed. Mozilla
staff (and I) would like to finalize this policy by this Friday, 10/12.
This draft includes a link to a Known Vulnerabilities page. Is it in a
good location? I plan to link to it from projects/security/index.html
and projects/security/components/index.html.
Do you like the names of the mailing lists,
security-bug-gr...@mozilla.org and security-bug-repo...@mozilla.org?
Should we use shorter names? I wanted to make it very clear what each
one is for.
-Mitch
[
security-bugs-draft7.html 17K ]
Handling Mozilla Security Bugs
Version 1.0
DRAFT 7
October 8, 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 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
"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,
has the primary responsibility for deciding when the bug
report should be opened for public scrutiny, and has the power to
do so.
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-bug-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-bug-reports@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.
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 bug group
As previously described, the
...
read more »
[
diff7 5K ]
*** security-bugs-draft6.html Mon Oct 8 20:00:15 2001
--- security-bugs-draft7.html Mon Oct 8 20:26:16 2001
***************
*** 1,6 ****
-
--- 1,5 ----
***************
*** 20,27 ****
Version 1.0
! DRAFT 6
! September 30, 2001
--- 19,26 ----
Version 1.0
! DRAFT 7
! October 8, 2001
***************
*** 194,205 ****
have visibility into all Bugzilla data hosted through
mozilla.org.)
!
The Mozilla security bug group will have a private mailing list
to which everyone in the security bug group will be subscribed. This
! list will act as the well-known address to which users can submit
! new security bugs, as well as a forum for discussing group policy
! and the addition of new members, as described below.
!
Other participants
--- 193,209 ----
have visibility into all Bugzilla data hosted through
mozilla.org.)
!
The Mozilla security bug group will have a private mailing list,
! security-bug-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-bug-reports@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.
Other participants
***************
*** 316,336 ****
complete bug report).
!
When a bug is put into the security group, the security
group members, bug reporter, and others associated with the bug
! will decide, either through comments on the bug or the security group
! mailing list, whether an immediate warning to users is appropriate
! and how it should be worded. This warning should mention the existence
! of a vulnerability, which features or modules are affected, and a
! workaround, if one exists. The module owner, a peer, or some other
! person they may designate will post this message to a
! "Known Vulnerabilities" page, which will be maintained at a well-known
! location on on www.mozilla.org. These messages will contain all of the
! information that the security group has agreed to be safe for
! immediate public disclosure. Mozilla distributors who wish to inform
! their users of the existence of a vulnerability may repost these
! messages to their own websites, mailing lists, release notes, etc, as
! long as they don't disclose any additional details about the bug.
The original reporter of a security bug has the primary
responsibility for deciding when that bug will be made public;
--- 320,354 ----
complete bug report).
!
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:
!
!
! - to inform Mozilla users and testers of potential security
! risks in the versions they are using, and what can be done to
! mitigate those risks, and
!
! - to establish, for each bug, the amount of information a
! distributor can reveal immediately (before a fix is available)
! without putting other distributors and their customers at risk.
!
!
!
A typical warning will mention the application or module
! affected, the affected versions, and a workaround (e.g. disabling
! JavaScript). If the group decides to publish a warning, the module owner,
! a peer, or some other person they may designate will post this
! message to the
!
! Known Vulnerabilities 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.
The original reporter of a security bug has the primary
responsibility for deciding when that bug will be made public;
***************
*** 370,376 ****
If disputes arise about whether or when to disclose information
! about a security bug, the security 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
resort."
--- 388,394 ----
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
resort."
|
