Hi all, In Berlin we realized that our Bug Severity page is confusing and that sec-critical and sec-high don't have a good distinction. We endeavoured to fix this, and think we have. We have:
1) Split the Web and Client Severity page into separate pages. (And updated them.) 2) Clarified the definition of sec-critical and sec-high 3) Clarified guidance on what we would like, and would not like, people to do. 1) The new pages are at: https://wiki.mozilla.org/Security_Severity_Ratings/Client https://wiki.mozilla.org/Security_Severity_Ratings/Web 2) sec-critical doesn't have a clear meaning today and it's often contradictorily assigned and interpreted. Going forward, sec-critical and sec-high will have no distinction in terms of type of bug technically speaking; but sec-critical indicates "urgent security issues that present an ongoing or immediate danger to users." It would include: - actively exploited or publicly disclosed vulnerabilities - vulnerabilities that are worm-able or exceptionally easy to exploit One detail - and change - of this redefinition is that vulnerabilities that would otherwise be a sec-high, but are publicly disclosed or fixed in an upstream third party library would be marked as critical. However, because many of these are not actually reachable in Firefox, once investigated and confirmed as such they will be re-classified. 3) As is the case currently, we ask that sec-critical/high/moderate/low as well as sec-other and sec-vector only be assigned by those with experience evaluating vulnerabilities in coordination with the security team (historically dveditz, Tyson, mccr8, jesup, tjr). (This is not intended to hamper teams (e.g. fuzzing) who work on security 'things' that need to hide them from assigning sec-other though.) sec-want and sec-audit are NEVER to be used for an actual, identified vulnerability - that should be a separate bug with an actual sec-critical/high/moderate/low rating. Otherwise; however, sec-audit and sec-want are encouraged to be assigned by anyone on anything they think those keyword applies to. (Including public bugs.) For example: "This code pattern is dangerous, we should review existing stuff' would be a private sec-audit bug. sec-want can apply both to client security ("Create a wrapper of foo() that performs security checks") and web security ("We should implement [new web security header]"). The csectype- keywords indicate the root cause of a vulnerability; e.g. csectype-intoverflow or csectype-priv-escalation . If you think you can identify a root cause of a bug; feel free to do so! We have a few whiteboard tags we're trying to promote the use of. [pixel-stealing] for side-channel attacks that leak user history or same-origin policy violations. [bad-ram?] for crashes suspected of hardware problems; and [fingerprinting] for privacy concerns relating to it. If you have security or privacy-related whiteboard tags you use today (or think should exist) please reply so we know about them and we can potentially add it to more bugs and get it on the page. Finally, as an additional note, we are performing a 'Security Bug Re-Triage' effort where we are looking at all security bugs in the platform, trying to close invalid ones, and re-raising particularly concerning ones for consideration. If you are a Triage Owner and want to know when we may come knocking, please email me. As part of this, we have opened a #critsmash channel on Slack that is a good avenue to ask questions like "Would you consider re-rating this security bug?" and raise concerns like "This is a sec-high but it involves months of work and we won't be able to get it done in a timely manner." -tom _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
