Security/Firefox/Security Bug Life Cycle/Security Advisories

From MozillaWiki
Jump to: navigation, search

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.

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.
  • ASAN Nightly bugs go into the roll-up advisory.
  • Sometimes we know a large library update will fix vulnerabilities, but we don't know _which_ vulnerabilities it fixes (often upstream does not assign CVEs, and we aren't allowed to assign CVEs for them) or if there are vulnerabilities at all (but we suspect there are.) We try to avoid this, but in these cases, it's acceptable to issue a CVE with details like e.g. 'Angle graphics library out of date' - 'An out of date graphics library (Angle) [likely] contained vulnerabilities that could potentially be exploited.'
  • 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 ./gen_queries.py 71 or ./gen_queries.py 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: 

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. This can lead to a use-after-free causing a potentially exploitable crash.


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.
  • The title should be a full sentence.
  • Function names and objects in the advisory description should be enclosed with <code> tags.
  • Description of the bug should not credit/mention the bug reporter again.
  • Check the ESR version number for decimal errors (e.g., 78.6000001).
  • Do not include IRC nicks in the reporter field.
  • 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.

Get review

Confirm with your reviewer (you should know who that is, if you don't, ask) ahead of time when they will be able to review, and make sure you have the yml files ready by that time.

Following that round, send the .yml files to the security-group list and solicit more feedback. If the release is on a Tuesday, this should be done no later than Friday evening.

Add them to the repository

// First time:
git clone https://github.com/mozilla/foundation-security-advisories
cd foundation-security-advisories
git remote rename origin origin-public
git remote add origin git@github.com:mozilla/foundation-security-advisories-private.git

// Every time:
git pull origin-public master
git checkout -b adv-131
// Add your yaml files
git commit
git push origin

The above instructions for setup will check out the public and private repos and will rename the public one so it's harder to accidentally push to it.

Each advisory cycle, you will update your local repo with the canonical source of truth (the public master branch), create a branch for yourself, you commit your files, and you submit the branch to the private repo.

Assign CVEs

Typically done a day or two before the release, assign CVEs to the bugs in bugzilla and in the yml file. This needs to be done by a person with CVE Services credentials and Bugzilla security access, and can be automated with the assign_cve_ids script in the foundation-security-advisories repository.

That script will automatically reserve new CVEs, insert them into the yml file, and set the CVE IDs as aliases on Bugzilla. You can use it by running pip i && assign_cve_ids in the root of the repository. You can provide the required credentials through the CVE_USER, CVE_ORG, CVE_API_KEY, CVE_ENV, and BUGZILLA_API_KEY environment variables. Before running the script, make sure to set the names of the advisories that should get a CVE ID to MFSA-RESERVE-{YEAR}-{BUG_ID}, where {YEAR} is the year that should be associated with the CVE, and {BUG_ID} is the id of a Bugzilla bug that should get the CVE ID as an alias. If you do not want to have a alias set for the advisory, use a small unique number instead. If you have used the gen_yml.py script from the previous step to generate your yml file, the advisories should already have this format.

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. This is very important. It is common (usually several times a year) for us to request Google to assign a CVE for an issue in an upstream library. The Googler to contact for this is Adrian Taylor, and Tom Ritter (among others) can put you in touch.

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

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 https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments, as well as publishing the actual CVE contents to CVE Services.

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&oldid=1252032"