Frank Hecker wrote:
> * Full information about security bugs will be restricted to a
> known group of people, using the Bugzilla access control
> restrictions described above.
>
> * 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.
>
> * 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.
>
What, if that bug or strongly related topics are discussed on the
mailing list? IMO, there should be a policy that those people are added
to the (email) cc list of such discussions.
Rationale:
* Bugzilla is not an ideal platform for longer discussions, thus it
sometimes makes sense to move a discussion which started in a bug
to a mailing list.
* Members of the security group might be tempted to move discussions
to the list specifically to exclude the reporter or other people
on the cc list. I don't think, this should happen, unless the
group at large decides so for good reasons.
Involvement of the original reporter is essential, because sometimes, he
is the only one involved who is really interested in getting the bug
fixed right. (This is nothing against anybody working on Mozilla, but a
general (sad) statement).)
> 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.
>
What is "legitimate"? "I want to fix a few security bugs."? "I want to
do a securty-audit of Mozilla."?
> 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.
>
But that "reasonable" must depend on the size of the Mozilla project.
The more people
> 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.")
>
I strongly believe that each new bug reported confidentally should
*immediately* be reported in a vage way to the public. See an older post
of mine for details.
E.g., we create a newsgroup .security-announce and whenever a security
bug gets reported, a certain person has the reposibility of posting a
summary (without details about how to exploit it) to that group.
I believe that the public has at least the right to know that there is a
bug and roughly where it is. This allows people to protect themselves,
e.g. by disabling JavaScript or avoiding to use Mozilla to submit
sensitive information in https HTML forms or whatever.
Rationale:
* There might be distributors who are denied join the security group.
* There are lots of people testing Mozilla by doing their day-to-day
work with it, and they have a right for their security too.
* Such a newsgroup is a convient and visible way to be warned and
notified about security bugs, for all parties:
* People new to the project will find the newsgroup very quickly
* Even people in the security bug group have a nice and
easily-tracked way to keep themselves informed.
* That newsgroup acts as public archive for very important
information about Mozilla. (Bugzilla might be down, mozilla.org
might cease to exist, etc.)
Also, in any case, distributors *must* have the right to inform their
users about the bug (in a vage way, but with suggested workarounds) as
soon as it has been discovered.
If a bug is fixed, a followup to the warning should be posted, saying
that the bug is believed to be fixed from build / CVS source x on.
> This level of generality informs users without potentially causing
> security "fire drills" for other Mozilla distributors.
>
Well, I believe that fire drills are good and necessary here. :-)
> 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.
>
I think that there should be mozilla.org-imposed limits to how long a
bug will be kept confidental.
To make my point, I see absolutely no reason to keep the bug confidental
after distributors issued release some time after the bug has been
reported. Even the least security-savvy computer user will be xx to hear
that his browser vendor released a product with severe security bugs in
it, which were known for some time. If security-concious people get to
know about that, it drives them up the wall and they generally loose all
trust in that vendor. I don't think, mozilla.org should support such
irresponsible treatment of security bugs.
(OK, there is a problem to determine when all distributors released a
new product after a bug has been found. Maybe we can settle at
mozilla.org stable releases or something like that.)
I go even further than say that mozilla.org should put some directed
pressure on its developers by making security bugs public after some
pre-defined amount of time. The pressure of publicity is the only
reliable way I know to get people fix security bugs in time and
correctly. Apart from pressure, publicity also gives more people a
chance to fix a bug.
I don't argue more, because that has been discussed extensively before
and I wonder, why this didn't make it in the mozilla.org policy draft.
The current scheme (see also my replies below) practically gives
Netscape the chance to keep security bugs confidental as long as it pleases.
> We believe that investing this power and responsibility in the bug
> reporter simply acknowledges reality:
>
Indeed. This "policy" is none. You simply never disclose security info.
I don't think that is right.
The current policy changes nothing to the current procedure, apart from
giving a few more people access to the bugs. In fact, in some cases, it
is worse: Today, Netscape makes all fixed bugs public some time after it
made a release. With the new policy, a bug which is forgotten by a
reporter might never be disclosed, unless someone pokes him. What, if
the reporter is not reachable anymore?
> However we will ask all individuals and organizations reporting
> security bugs through Bugzilla to follow the voluntary guidelines below:
>
> * Please try not to keep bugs in the security-sensitive category
> for an unreasonably long amount of time.
>
You have to define that.
> 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.
>
I think that should happen visibly to all members of the seucrity group,
not just the 2 parites in conflict. Otherwise, Netscape or somebody else
might talk a reporter into keeping the bug closed longer than reasonable.
BTW: Why do we have to wait for distributors to release a new version of
their product? I think that it is technically and organizational
possible to push important fixes to users.
At Beonex, I added a default bookmark, which exploits the change
notification feature in Mozilla to display new security alerts to users.
The page is checked each time Communicator starts, at most once a day.
If the alert webpage changed, a window pops up displaying it. On the
page, the problem is described (vagely) and a suggestion for a fix or
workaround is suggested, e.g. to install an XPI which contains the fixed
dll.
Note that this works even through firewalls, assuming the web can be
accessed at all.
This approach is not perfect but could be made to work well with not too
much effort. This would allow Netscape and others to quickly distribute
security fixes to all users.
(I am a bit concerned about letting the browser "call home", but I value
security over the minor privacy problem here. Netscape surely has no
chance to object to that, since its browser "calls home" at every
possible time anyway.)
In other words, I can't even see a good reason to wait for a new release
of any distributor before making fixed bugs public. But then again,
didn't I argue exactly this way before already?
> 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.
>
Rationale? I would think that if any of the reporters decided to
piblicize the bug, all dups can be made public, because they are
practically anyway.
>
> 0.1. 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.
>
I think that the Mozilla community at large must have a word in this,
not just the security bug group.
> 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.
>
It isn't meant as offening as it might sound, but while you *considered*
all views, the view of Netscape is about the only one followed in this
policy. You have neither full disclose nor disclosure after a certain
amount of time. Everything is controlled by a small, hand-picked group
of people.
