The proposed change allows an employee with information important to his or her company's product to share that information within his or her company. This is necessary to allow distributors of Mozilla technology to function effectively. It is not enough for an individual to know of a security flaw in Mozilla if s/he is prevented from describing it and allowing a distributor to make rational decisions about their product. I believe the change reflects the existing intent of the security group, but not our stated policy.
The change is in the section titled "Disclosure of Security Vulnerabilities" and that section is below. The proposed change is in green. (The version number and date of the document would of course change as well.) The entire document (not reflecting the proposed change) can be found at http://mozilla.org/projects/security/security-bugs-policy.html
The document has HTML formatting, which I have not tried to remove for this message.
Mitchell
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, except that if a member of the Mozilla security bug group is employed by a distributor of Mozilla-based products, then that member may share such information within that distributor, provided that this information is shared only with those who have a need to know, only to the extent they need to know, and such information is labeled and treated as the organization generally treats confidential material
- 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 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 (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.
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 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.)
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 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.
