canmove, Confirmed users
637
edits
Security/Firefox/Security Bug Life Cycle: Difference between revisions
Security/Firefox/Security Bug Life Cycle (view source)
Revision as of 06:58, 10 March 2020
, 10 March 2020Fixing queries to find older fixed bugs
m (edit suggestions from Thyla) |
(Fixing queries to find older fixed bugs) |
||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
Security bugs in our product put millions of people at risk. To fulfill Mozilla's mission we must discover those bugs, fix them, and ship the fixes. This process involves multiple teams across the organization. This page describes a bug-centric view of the tasks that are part of that process, serving almost as a checklist to make sure we are executing on each step. There are also handy bugzilla queries that will be helpful for people as they work on each task. | |||
Since this is a bug-centric view there are many important activities performed by Mozilla security teams that are not mentioned, or only briefly. Fuzzing, static analysis, and other research are an input into this process, serving as a source of bug discovery--and much preferred to bugs being found in the wild. The analysis step described in this page can be an input to the efforts to harden Firefox against exploits (for example, sandboxing, site-isolation, and mitigating XSS in privileged UI code). | |||
'''Note:''' The bugzilla links in this document are intended for the people performing the tasks described in the sections where they are found. Most of them will yield empty or incomplete results unless you are logged in to bugzilla.mozilla.org and have access to security bugs. | |||
= A Bug is Born = | = A Bug is Born = | ||
| Line 16: | Line 24: | ||
= Security Triage = | = Security Triage = | ||
== Incoming == | == Incoming == | ||
| Line 38: | Line 44: | ||
== VulnSmash == | == VulnSmash == | ||
We must make sure the most severe security bugs are kept on track. For these bugs: | We must make sure the most severe security bugs (critical and high) are kept on track. For these bugs: | ||
* Set the priority to P1 | * Set the priority to P1 | ||
** This matches the Firefox project's definition of "Fix in this release", which is also roughly our required time-to-fix for security bugs of this severity. See the [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage triage guide]. | |||
** It may be appropriate for engineers to lower the priority later after consulting with their manager and the security team. P1 is the default absent an explanation of why it's necessary to keep our users at severe risk. | |||
* Set the appropriate version status flags to “affected” | * Set the appropriate version status flags to “affected” | ||
* Set the version tracking flags to “+” | * Set the version tracking flags to “+” | ||
| Line 46: | Line 54: | ||
[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20-kw:stalled&order=Last+Changed '''Open sec-critical and sec-high bugs'''] ([https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical&order=Last+Changed include stalled]) <br> | [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20-kw:stalled&order=Last+Changed '''Open sec-critical and sec-high bugs'''] ([https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical&order=Last+Changed include stalled]) <br> | ||
[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20-kw:stalled%20%40nobody '''Unassigned sec-critical/sec-high bugs'''] ([https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20%40nobody include stalled]) | [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20-kw:stalled%20%40nobody '''Unassigned sec-critical/sec-high bugs''']([https://bugzilla.mozilla.org/buglist.cgi?quicksearch=class%3Aclient%2Ccomp%20kw:sec-high%2Csec-critical%20%40nobody include stalled])<br> | ||
[https://mzl.la/2PJblUW '''Sec-critical/sec-high bugs without a priority'''] | |||
== Administrivia == | == Administrivia == | ||
| Line 77: | Line 85: | ||
== Landing Fixes == | == Landing Fixes and Tests == | ||
External parties watch check-ins in order to identify security patches [https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome/][https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html], and we have both documented and suspected cases of this for Firefox patches. We don’t want to 0-day ourselves by landing obvious fixes that sit in the tree for a long time before they are shipped in an update, and we especially don't want to land test cases that demonstrate how to trigger the vulnerability. The [https://wiki.mozilla.org/Security/Bug_Approval_Process '''Security Bug Approval Process'''] is designed to prevent that. Part of the approval process is evaluating what bugs need to be pushed to Beta and which are risky and need to ride the trains, and whether or not the patch is needed on supported ESR branches. | |||
Testcases for vulnerability fixes should be split into a separate patch for this "sec-approval" process. These testcases should land ''after'' we have shipped the fix in Release, usually by a few weeks to give users time to have applied the update. We '''must''' track the task of landing these patches later. You have two main options and either is fine. A task bug is more upfront work but more straightforward; the flag is easy but requires more follow-up. | |||
:'''Option 1:''' Create a task bug assigned to yourself ("Land tests for bug XXXX") that depends on the vulnerability bug. It must be a hidden security bug like the main vulnerability. Add the keyword <code>sec-other</code> | |||
:'''Option 2:''' Track it in the original bug using the <code>in-testsuite?</code> flag. If you go this route you must remember to check for un-landed tests (queries below). Once the tests are landed change the flag to <code>in-testsuite+</code> | |||
[https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&f3=status_whiteboard&j2=OR&f5=CP&v1=in-testsuite%3F&v4=sec-&o1=substring&o4=substring&f1=flagtypes.name&f4=keywords&f2=OP&v3=%5Bsg%3A&emailassigned_to1=1&emailtype1=substring&email1=%25user%25&o3=substring&list_id=15143453 '''"My" security testcases that need landing'''] (personalized)<br> | |||
[https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&f3=status_whiteboard&j2=OR&f5=CP&v1=in-testsuite%3F&v4=sec-&o1=substring&o4=substring&f1=flagtypes.name&f4=keywords&f2=OP&v3=%5Bsg%3A&o3=substring&limit=0 '''All unlanded testcases for fixed security bugs''']<br> | |||
[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20sec-approval%3F '''Pending sec-approval requests'''] | [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20sec-approval%3F '''Pending sec-approval requests'''] | ||
<br> | |||
<br> | |||
== Verifying Fixes == | == Verifying Fixes == | ||
| Line 96: | Line 115: | ||
== Security Advisories == | == Security Advisories == | ||
The fixed bugs that had been present in a shipped release need to have a CVE assigned and to be written up in our release advisories. Security fixes for recent regressions that only affected Nightly or Beta don’t need an advisory. [ | The fixed bugs that had been present in a shipped release need to have a CVE assigned and to be written up in our release advisories. Security fixes for recent regressions that only affected Nightly or Beta don’t need an advisory. [https://wiki.mozilla.org/Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories Advisory instructions] | ||
For historical write-ups see our | For historical write-ups see our | ||
[https://www.mozilla.org/en-US/security/advisories/ '''Published advisories''']. | [https://www.mozilla.org/en-US/security/advisories/ '''Published advisories''']. | ||
== The Pit of Despair == | == The Pit of Despair == | ||