Security/Firefox/Security Bug Life Cycle/Security Advisories

From MozillaWiki
Jump to: navigation, search


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

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.


Determine what bugs will get advisories


  • 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. I use a script that generates the bugzilla query for a given version. For example ./ 71 or ./ 71 -v
  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:



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 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: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.

Review it yourself

  • We use the past tense when writing about vulnerabilities
  • The titles of bugs do *not* use Title Case, they use Sentence Case.
  • Function names and objects should be enclosed with <code> tags
  • JavaScript not javascript
  • use-after-free not 'use after free'
  • Check if there are no community members on the rollup, and if so, remove that bit

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. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)

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

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.


Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private repo. Release management will pull from this repo and commit it to the public repo which will make them live on the site in moments.