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

[ security-bugs-draft6.html 17K ]

Handling Mozilla Security Bugs

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 ...

read more »

[ diff6.txt 2K ]
*** 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>

*kiss*

Mike

Mitch, thanks for doing this. I'm still bogged down in writing stuff for
work, and haven't been able to do another draft myself. Thanks also to
you and everyone else for participating in the n.p.m.security discussions.

The only comments I  have are concerning typos and style:

1. In addition to changing the document draft number, please change the
date in the document when/if you do any future drafts.

2. All occurences of the term "security group" should be changed to
"security bug group" for consistency within the document.

3. You have a duplicated word "on on" in one of the sentences right
before "www.mozilla.org".

4. Instead of  "... on www.mozilla.org", please write "... on the
mozilla.org web site" and make "mozilla.org web site" a link to
"http://www.mozilla.org/".

Also, just to be sure nothing broke HTML-wise, please validate the file
at http://validator.w3.org for HTML 4.01 strict compliance if you
haven't already done so.

I'll rejoin the general discussions on n.p.m.security as soon as I have
spare time available; my apologies for my absence the past two or three
days.

Frank

--
Frank Hecker
hec...@mozilla.org

"Consensus" is such a thing. Do we have consensus on a security policy
for Mozilla? No.

That's much less than you said were OK in your last posts and much less
than I need. You now constrain the info I give my users to what you
publish for Mozillam, while yesterday, you said "You can inform *your*
users via your mailing list, release notes, etc, as long as you make an
effort not to provide enough information to allow someone to reproduce
the bug".

I want to issue warnings (to my users)

   1. for *all* bugs I consider severe enough and
   2. in I wording I choose, with content I choose (as long as I don't
      disclose reproduction info or something close to it)

Rationale:
2., because my users are of course less technically savvy than Mozilla
contributors, and the workarounds are also likely to be different for
Beonex Communicator (different default settings, different install
strategy etc.). I might even need to reveal more (still vage) facts
about a bug than the official warning does, when I think that this is
necessary for my users to judge their risk and to work around the bug.
Reaching "consensus" also takes time, more time than is acceptable for
me in some situations.

1.: please try to understand my situation. I see a bug, know that users
risk their whole network security because of that buffer overflow, and,
for any reason, the reporter or the security group decides not to issue
a warning, so I am not allowed to warn my users. That's unacceptable and
cruel (sorry for the hard word, but that's how I feel about it).

If you want to prepare the warnings for mozilla.org, incl. their
wording, in the security group, that's certainly fine with me.
BTW: I wouldn't define a web-"page", because I think that
newsgroups/mailing lists are the best method to publish such urgent and
important info. Having the same info additionally on a webpage is surely
nice, though.

Great!

If a bug is security-confidential, then some form of warning will be
agreed (unless none of the participants requests that one be agreed.) If
it's not, you can publish what you like. So, as I understand it, no-one
will prevent you from issuing a warning of some form.
On the other hand, take the GIF overflow bug in NS 4.77 as an example.
If we had a bug like that, are you really going to warn your users to
disable images? If not, there's no point in issuing any warning at all
until there's a fix available.

I think that the answer to this is basically "you can't have it." Sorry
to sound cruel or harsh, but there it is. All vendors, including
Netscape, will publish only what the group agrees on. Why should you be
different?

Let's look at the other situation. Neither you nor your users find out
about the bug because it's been filed in Bugscape. Netscape keeps it
quiet for as long as it likes, and meantime your users get shafted by
the skript kiddies exploiting it.

I'm not saying that this possibility allows Netscape to dictate the
terms of the entire security group proposal without discussion; I am
merely making the point that the usefulness of the group goes up with
the number of the participants, in proportion to what those participants
contribute. If Netscape feels it can't contribute because it can't be
sure you aren't going to shaft _their_ users, then they won't. And
everyone loses.

I think Mitch is saying that the web page (which has checkin and change
control) is the master source, and anyone can disseminate whatever they
want wherever they want from that page.

Gerv

How about having a sublist to which users can send reports of new security
bugs, so not all members of the list have to recieve all the spam?

Reporters are unlikely to care about the bug several months after it is
fixed, and are even less likely to care enough to ask permission to open it.
Reporters should have the *ability* to open bugs to the public, but they
should not be relied upon to make their bugs public several months after the
bugs are fixed.   That responsibility should lie elsewhere (hi BenB).

.../discussion.

Agreed. <secur...@mozilla.org> should be reserved for new reports, not
used for long discussion.

Ex-act-ly.

Wave :).

  Gervase Markham wrote:

What if not? What if it takes too long? What if it's inappropriate for me?

Maybe. Maybe I'm going to warn them to possibly not use the browser at all.

Then I think my answer to this will basically be "Then I don't want to
play with you".

Weren't we talking about consensus?

And I am saying that too "liberal" terms in the security bug group make
it useless for me, no matter if anybody participates or not.

How am I going to "shaft" their users??

Which I think is wrong. You cannot ask me to reload the page every 3
hours, if I want to be sure to get the latest warning.

If you ask in the bug for the participants to agree a warning text, one
should be agreed. If you want that stated in the policy, say so - but it
seems like common sense to me.

You have to raise those concerns in the group. Others may share them. A
form of words will be reached. This is consensus :-)

That would be unfortunate, as I believe your users would lose out if you
were not a member of the security group.

We were. But it appears we have reached an impasse. You will not accept
being told what you can and cannot say by the security group; Netscape
will not accept you being permitted to say whatever you like and perhaps
hurting their users by being over-generous with vulnerability information.

If you claim that the latter could never happen, then you should have no
objection to saying only what is agreed by the group.

As I understand it, the entire reason that this web page announcement
proposal has been put forward is so that a member of the security group
does not (advertently or inadvertently) reveal information which leads
to trouble for the users of other members' software. This is why what is
said must be agreed upon.

You as a distributor of Mozilla-based products, or you as an end-user?
As a distributor, you will be a member of, and active in, the security
group and involved in any discussions which lead to a post on the page.
As an end-user, you should not be referring to that page at all, but to
whatever mechanism the distributor of your software has for notifying
you of security problems.

Gerv