Security/Firefox/Security Bug Life Cycle/Security Advisories

Background

This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/

The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.

Note: This document is going to be incomplete until Tom does the 71 security advisories, and then he can refine the page.

The previous document is here and this page will eventually supplant it, but it's not done yet.

Process

Determine what bugs will get advisories

Criteria

- All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. - Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion. - Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues. - Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release. - Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up". - Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.

Tag them

1. Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. TODO: Link to query generator
2. For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.
   1. The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.
   2. [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.

Write the advisories

On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:

Title
Reporter

Description

for example:

Memory corruption when processing WebRTC messages
John Doe

When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.

Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.

Generate and edit the YML File

Using TODOXXX this script, generate a first-pass at the .yml file.

Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: editing the list of reporters in the rollup advisory. That must be done manually and cannot be done in-bug.

Get review

Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.

Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.

Assign CVEs

Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated.

A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a feed: false in the advisory, after reporter.

A CVE ID from Mitre is assigned from our CVE pool of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.

The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)