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

Reports of security vulnerabilities come from many different sources. Many are directly filed as security bugs by various groups including:

* Our security teams (via fuzzing, static analysis, security reviews and audits)

* Engineers developing, reviewing, or testing may notice vulnerabilities as they work on non-security bugs

Some issues are found outside of the Mozilla community. The security team or other Mozilla community members file bugs for these issues when they come to our attention via:

The main goal at this stage is to get security bugs rated appropriately and into the purview of the engineers who manage the relevant areas of code. Only a limited number of people can see security bugs by default so we need to ensure that each bug is in the right security group and CC additional people as necessary. When triaging, consider the following for each bug:

* Is it in the right security group for the component (''especially'' if it’s in the “Core” product)? See [https://securitywiki.mozilla.org/Client_Security_Teams#Development_Teams Security teams and components] for a mapping between security groups and components.

* Are the appropriate developers CC’d so they can see the bug and needinfo'd so they are aware of it?

* If you can't select an appropriate [https://wiki.mozilla.org/Security_Severity_Ratings security severity rating], needinfo? someone for help. This is typically either a senior security team member or a senior engineer in that area of the code.

* Assign to an appropriate owner (if there’s no better person use the Triage Owner)

Once a fix lands the security group on that bug should be changed to the “Release-track” group (core-security-release) so that QA can see and verify the bugs.

 

 

Severe security bugs need to be fixed with deliberate speed to protect our users. In addition, some external reporters have a disclosure deadline such as 60 or 90 days before they report the issue publicly.

* Sec-high bugs should be fixed within a few weeks: 6 weeks maximum is a good goal. 60 days is a common disclosure deadline, and in addition to writing the patch, we have to account for time spent on QA and the release process as a whole.

We know people watch our check-ins and we don’t want to 0-day ourselves by landing obvious fixes and 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.

It's generally important to have bug fixes tested by fresh eyes who might catch problems with incorrect assumptions made by the original fix. This is especially important for security fixes because we announce these fixes in our advisories: if the fix doesn't work we put people at risk. Verification is especially important when we uplift/back-port patches to the Beta or, worse, the ESR branches since they're more likely to suffer from subtle dependencies on code changes from normal trunk development that weren't back-ported to those branches.

[https://wiki.mozilla.org/Release_Management/ESR_Landing_Process '''ESR landing process'''] page for additional release-management triage queries.

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. [link to Al's doc]

Sometimes we can't make much progress on finding and fixing a security bug, especially if we don't have a reliable way to reproduce it. This is a particular problem with crashes filed from crash-stats reports. They are real bugs, they may even happen fairly often, and the crash stacks show memory corruption that is likely exploitable if it can be triggered reliably. These should be filed and treated as security vulnerabilities because we do manage to fix a significant number of them when we investigate. However, many others are generic and the crash is detected so far after the actual cause of corruption that we can't make progress. These bugs are given the keyword "stalled" and removed from active work. There are sometimes ways to make further progress (e.g. diagnostic asserts might be added to narrow down theories about what is going wrong), but once all ideas are exhausted and there is no longer any hope for further progress many of these bugs are eventually going to have to be closed as INCOMPLETE.

The [https://addons.mozilla.org/en-US/firefox/addon/open-selected-links/ Open Selected Links] extension can be helpful for opening multiple bugs at once from a buglist during triage. It also has a "View link source" context menu item that can be useful for inspecting testcases.