Security/Firefox/Security Bug Life Cycle/Security Advisories: Difference between revisions

Security/Firefox/Security Bug Life Cycle/Security Advisories (view source)

Revision as of 10:02, 10 November 2023

185 bytes removed , 10 November 2023

Update "Assign CVEs" section to explain the new assignment process

Mjurgens

3

edits

@@ Line 11: / Line 11: @@
 ==== 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.
@@ Line 33: / Line 33: @@
   Title
   Reporter
   Description
@@ Line 40: / Line 40: @@
   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.
@@ Line 65: / Line 65: @@
 * Check if there are no community members on the rollup, and if so, remove that bit.
-=== Assign CVEs ===
+=== Get review ===
-Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file.  This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt
+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.
-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.
+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.'''
-A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit 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.
+=== Assign CVEs ===
-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.)
-==== Oh no, I don't have enough CVEs! or Oh no, Google never got back to me! ====
+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 [https://github.com/mozilla/foundation-security-advisories foundation-security-advisories] repository.
-That's alright.  Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number (like MFSA-TMP-2023-001). Everything will work fine. Later when we have the CVE, go back and assign it.  It's hard to keep track of TMP numbers, but this is uncommon. A command like <code>git grep "MFSA-TMP" $(git rev-list --all -- announce) -- announce/</code> will show you any uses, even if they've been correct in the file.
+That script will automatically reserve a new CVEs, insert them into the yml file, and set the CVE IDs as aliases on Bugzilla. You can use it by running <tt>pip i && assign_cve_ids</tt> 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 [[#Generate_and_edit_the_YML_File|'''gen_yml.py''' script from the previous step]] to generate your yml file, the advisories should already have this format.
-[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]
+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.
-n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So for now on we use the MFSA-TMP prefix to distinguish. We also previously used the MFSA-YEAR-# format for individual issues from 2005ish - 2016.
+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 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.'''
 === 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.
+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.