Mozilla.org Publishes Security Policy

benb from Beonex writes: "mozilla.org agreed upon a policy how to handle reports about severe security vulnerabilities. It is about to be implemented. In the future, you will find information about most security bugs at the known vulnerabilities page; there will also be an announce mailing list. In case you are interested, you can read my own review (and the security module owner's response) of the policy."

Nice, but what does it mean in practice?

[Outland Traveller]

I believe that it's a good thing to have a security policy. However, there are lots of vulnerability forums that are much larger in scope than Mozilla.

What does it matter what Mozilla's official vulnerability warning policy is when you can get the info from bugtraq etc?

Re:Nice, but what does it mean in practice?

[Anonymous Coward]

I thought the point is that bugs will be stored on BugTrack but not publicly available until a small group of security people certify it to be (and they have to send round a global email to each other.) This means that security problems will be reported but not particularly publicly. I am concerned, however, that the Mozilla team may not be taking security bugs as seriously as it could if it's refusing to publish what's happening.

Does the policy CREATE vulnerability?

[phr1]

The principle of the "full disclosure" movement is that once a bug is known to attackers (black hats), it's best to publish it, so users can take countermeasures; and since black hats find out about things quickly no matter what you do, it's best to publish immediately or almost immediately. The more traditional (and basically failed) view is to keep things secret from regular users in order to prevent black hats from finding out. Optimally, black hats never learn the bug, but that's extremely risky to rely on in practice. Full disclosure instead avoids the pessimal situation, where regular users don't know they're vulnerable, but black hats do know.

Mozilla's policy tries to strike a balance by keeping the bug temporarily under wraps, and disclosing it once there's a way to deal with it. This is a reasonable idea. How will it be implemented?

1. There will be this big mailing list (the security group) notified of all security bugs. It will have dozens or hundreds of people, and it sounds like it will be sent by unencrypted email. Of course that's inherently insecure. It's implausible to me that this mailing list won't quickly find itself gatewayed to a black hat list, either by being intercepted somehow or by a black hat managing to get on it. Even if the mail isn't systematically forwarded, there's a saying that once 3 people know something, it's not a secret. So if dozens or hundreds know about a bug, the black hats know it.

2. The idea of mozilla.org staff serving as a court of last resort for disputes about whether to disclose a bug sounds hopelessly naive for anyone used to the dynamics of large mailing lists. If there's a dispute about whether to disclose a bug and an argument breaks out, someone will press the button to disclose the bug before it ever reaches any kind of "court". That will end the disclosure question, though recriminations may begin at that point.

3. Sooner or later someone is likely to push a button to disclose all the outstanding bugs. There will be a big ruckus, the discloser will get booted from the list, hell may break loose with exploits, but eventually things will get back to normal. Sooner or later, the process will repeat.

Maybe I'm being cynical and the security group will be more mature than I've described, but I'll believe it when I see it.

Re:Does the policy CREATE vulnerability?

[benb]

> The principle of the "full disclosure" movement
> is that once a bug is known to attackers (black
> hats), it's best to publish it, so users can
> take countermeasures

No, full disclosure is to make *all* information about security bug available publically, even those bugs that are found by the good guys ("white hats") and reported to the vendor/project only.

Once a bug is public, there is no point not to admin it as vendor/project (unless you want to hide your errors, which I don't think is a good strategy).

> and since black hats find out about things
> quickly no matter what you do

That's wrong.

> Optimally, black hats never learn the bug, but
> that's extremely risky to rely on in practice.

Agreed.

> disclosing it once there's a way to deal with it

No, mozilla.org won't disclose it until half a year later.

> So if dozens or hundreds know about a bug, the
> black hats know it.

It will probably in the area of dozens, and handpicked.

I think, you overestimate black-hats' capabilities. They have the source. Did they ever find a bug themselves?

> someone will press the button to disclose the
> bug before it ever reaches any kind of "court"

In which case that someone will the longest time have been a member of the group, most likely.

> hell may break loose with exploits

Let's not hope that there will be so many known and unfixed vulnerabilities at any given time ;-).

Disclosure will take under six months

[Max Hyre]

Unless benb has information absent from the policy (perfectly possible, as I gather he was in on its creation), I don't see how he can state:

> No, mozilla.org won't disclose it until half a year later.

In the declaration's early section labelled General Policies , we find:

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, and has the power to open the bug report for public scrutiny.
[Emphasis added]

And toward to the end, in the section Disclosure of security vulnerabilities :

Please try not to keep bugs in the security-sensitive category for an unreasonably long amount of time.

Thus, unless the discoverer is a member of the security group, the original submitter's right to uncloak the report says to me there's no way a bug could be stifled for six months, and further, they're asking that it not be.

YMMV, of course.

Re:Disclosure will take under six months

[benb]

> > No, mozilla.org won't disclose it until
> > half a year later.

Sorry, I should have said "3-9 months".

> Please try not to keep bugs in the
> security-sensitive category for an unreasonably
> long amount of time.

Yes, but the very next request is

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

"a Mozilla distributor" reads "Netscape". :-/ Netscape releases about every 6 months.

> the original submitter's right to uncloak the
> report says to me there's no way a bug could be
> stifled for six months, and further, they're
> asking that it not be.

Unfortunately, no. Unless the reporter (discoverer) chooses to ignore mozilla.org's request (which is his right), the bugs will indeed often stay closed for 6 months.