In light of objections people have raised on the newsgroup, and after talking to some Netscape and Mozilla folks, I'd like to propose some more changes to our security group proposal. I've attached a new draft and diffs below.
The major change is some language about putting a Known Vulnerabilities
page on mozilla.org. The following is Gerv's idea, and I think it's a
good one. Our major sticking point with this policy seems to be how much
information vendors (and Mozilla) can disclose about a vulnerability
before it is fixed. To prevent any misunderstanding about that, when a
security bug (vulnerability) is filed, let's decide in the bug how much
information is safe to reveal immediately. Obviously, everyone who has
access to the bug will have input into this. Then we'll post a message
on a Known Vulnerabilities page, similar to what other open source
projects maintain. Then, any Mozilla vendor or distributor who wants to
inform their users about the existence of a bug can use the information
from the Mozilla page, but no more.
As module owner, I'd be happy to maintain that page, along with whoever
we pick as peers. As with the rest of this proposal, I expect that the
amount of information disclosed on the public page will be decided by
consensus among the security group on a per-bug basis.
The other change I made was to the language about disputes over when a
bug should be taken out of the security group. Instead of recommending
private negotiations between parties, we should emphasize open
collaboration on the security group mailing list.
Please let me kno what you think of these changes.
-Mitch
Title: Handling Mozilla Security Bugs
Handling Mozilla Security Bugs
DRAFT 6
September 30, 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 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
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 Mozilla security module owner can select one or more peers to share the core work of coordinating investigation and resolution of Mozilla security vulnerabilities, and will work with them to create some agreed-upon ground rules for how this work can be most effectively shared among themselves. As with other Mozilla modules, we intend that this core group (module owner plus peers) remain small; its membership should change only infrequently and only after consultation with mozilla.org staff.
The security module owner and peers will also work with mozilla.org to populate the initial security bug group. We expect that the Mozilla security bug group will initially be significantly larger than the core group of module owner and peers, and that it may grow even further over time. New members can be added to the Mozilla security bug group as follows:
- New people can apply to join the security bug group, or may be recruited by existing members. Applicants for membership must have someone currently in the security bug group who is willing to vouch for them and nominate them for membership. Nomination is done by the "voucher" sending email to the security bug group private mailing list.
- The applicant's nomination for membership will then be considered for a period of a few days, during which members of the security bug group can speak out in favor of or against the applicant.
- At the end of this period, the security module owner will decide to accept the applicant or not, based on feedback and objections from the security bug group in general and from the module owner's peers in particular. If anyone else in the security bug group has a problem with the module owner's decision then they can appeal to mozilla.org staff, who will make the final decision.
The criteria for membership in the Mozilla security bug group are as follows:
- The applicant must be trusted by those already in the group.
- The applicant should have a legitimate purpose for wishing to join the group.
- The applicant must be able to add value to the group's activities in some way.
In practice, if over time a particular person happens to be frequently added to the CC list for security-sensitive bugs then they would be a good candidate to be invited to join the security bug group. (As described previously, once added to the security bug group that person would then have automatic access to all bugs marked security-sensitive, without having to be explicitly added to the CC list for each one.)
Note that although we intend to make it relatively simple for a new person to join the security bug group, and we are not limiting the size of the group to any arbitrary number, we also don't want the group to expand without any limits whatsoever. We reserve the right to cap the membership at some reasonable level, either by refusing new applications or (if necessary and appropriate) by removing some existing members of the security bug group to make room for new ones.
Disclosure of security vulnerabilities
The security module owner, peers, and other members of the Mozilla security bug group will not be asked to sign formal nondisclosure agreements or other legal paperwork. However we do expect members of the group
- not to disclose security bug information to others who are not members of the Mozilla security bug group or are not otherwise involved in resolving the bug,
- not to post descriptions of exploits in public forums like newsgroups, and
- to be careful in whom they add to the CC field of a bug (since all those CC'd on a security bug potentially have access to the 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; 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 outside the context of the Mozilla project. By not doing so, and by instead choosing to report bugs through the standard Bugzilla processes, the bug reporter is doing a positive service to the Mozilla project; thus it makes sense that the bug reporter should be able to decide when the relevant Bugzilla data should be made public.
However we will ask all individuals and organizations reporting security bugs through Bugzilla to follow the voluntary guidelines below:
- Before making a security bug world-readable, please provide a few days notice to the Mozilla security bug group by sending email to the private security bug group mailing list.
- Please try not to keep bugs in the security-sensitive category for an unreasonably long amount of time.
- Please try to be understanding and accomodating if a Mozilla distributor has a legitimate need to keep a bug in the security-sensitive category for some reasonable additional time period, e.g., to get a new release distributed to users. (Regarding this point, if all Mozilla distributors have a representative on the security bug group, then even if a bug remains in the security-sensitive category all affected distributors can still be informed and take appropriate action.)
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."
A final point about duplicate bug reports: Note that security bugs marked as duplicates are still considered separate as far as disclosure is concerned. Thus, for example, if a particular security vulnerability is reported initially and then is independently reported again by someone else, each bug reporter retains control over whether to publicly disclose their own bug, but their decision will not affect disclosure for the bug reported by the other person.
Changing this policy
This policy is not set in stone. It is our hope that any disputes that arise over membership, disclosure, or any other issue addressed by this policy can be resolved by consensus among the Mozilla security module owner, the module owner's peers, and other security bug group members through discussions on the private security bug group mailing list.
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.
*** security-bugs-draft5.html Mon Oct 1 17:07:05 2001 --- security-bugs-draft6.html Wed Oct 3 15:10:56 2001 *************** *** 20,26 **** <div class=version> Version 1.0<br> ! DRAFT 5<br> September 30, 2001 </div> --- 20,26 ---- <div class=version> Version 1.0<br> ! DRAFT 6<br> September 30, 2001 </div> *************** *** 316,328 **** complete bug report).</li> </ul> ! <p>Mozilla distributors participating in security bug group activities ! can mention in their release notes that a security bug has been ! fixed, but we ask that they be vague and not describe the exploit ! in detail. (For example, a release note could say, "This release ! fixes a serious security bug involving HTML form submission.") ! This level of generality informs users without potentially causing ! security "fire drills" for other Mozilla distributors.</p> <p>The original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; --- 316,336 ---- complete bug report).</li> </ul> ! <p>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.</p> <p>The original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; *************** *** 362,369 **** </ul> <p>If disputes arise about whether or when to disclose information ! about a security bug, we ask that the parties involved discuss ! the issues via private email and try to reach consensus. If necessary mozilla.org staff will serve as the "court of last resort."</p> --- 370,377 ---- </ul> <p>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."</p>
