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

Comments

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.

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.