|
|
| (10 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| ==Purpose: don't 0-day ourselves== | | = MOVED = |
| People watch our check-ins. They may be able to start exploiting our users before we can get an update out to them if
| | = This page moved to [https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html Firefox Source Docs: Security Bug Approval Process] = |
| * the patch is an obvious security fix (bounds check, kungFuDeathGrip, etc.)
| |
| * the check-in comment says "security fix" or includes trigger words like "exploitable", "vulnerable", "overflow", "injection", "use after free", etc.
| |
| * comments in the code mention those types of things or how someone could abuse the bug
| |
| * the check-in contains testcases that show exactly how to trigger the vulnerability
| |
| | |
| ==Principle: assume the worst== | |
| * If there's no rating we assume it could be critical
| |
| * If we don't know the regression range we assume it needs porting to all supported branches
| |
| | |
| ==Process==
| |
| For security bugs with no sec- severity rating assume the worst and follow the rules for sec-critical. If you have experience fixing security bugs you could also take a crack at rating it yourself following the [[Security_Severity_Ratings]]. If you have any questions or are unsure about anything in this document contact us on IRC in the #security channel or ask a senior developer who has worked on a lot of security bugs.
| |
| | |
| Core-security bug fixes should just be landed by a developer without any
| |
| explicit approval if:
| |
| | |
| '''A)''' The bug has a sec-low, sec-moderate, sec-other, or sec-want rating.<br> '''<u>or</u>'''<br>'''B)''' The bug is a recent regression on mozilla-central. This means
| |
| * A specific regressing check-in has been identified
| |
| * The developer can ('''and has''') marked the status flags for ESR, Beta, and Aurora as "unaffected"
| |
| * We have not shipped this vulnerability in anything other than a nightly build
| |
| | |
| If it meets the above criteria, check that patch in.
| |
| | |
| Otherwise, if the bug has a patch *and* is sec-high or sec-critical, the developer should set the sec-approval flag to '?' on the patch when it is ready to be checked into mozilla-central (or elsewhere if it is branch only).
| |
| | |
| If you have a patch and the bug is a hidden core-security bug with no rating then either:
| |
| # request sec-approval (to be safe) and wait for a rating, <br>'''OR'''
| |
| # rate it following the [[Security_Severity_Ratings]] and then proceed according to whether the bug is low/moderate or high/critical as above.
| |
| | |
| If developers are unsure about a bug and it has a patch ready, just mark the sec-approval flag to '?' and move on. Don't overthink it!
| |
| | |
| An automatic nomination comment will be added to bugzilla when sec-approval is set to '?'. The questions in this need to be filled out as best as possible when sec-approval is requested for the patch.
| |
| | |
| It is as follows (courtesy of Dan Veditz):
| |
| | |
| : [Security approval request comment]
| |
| : How easily can the security issue be deduced from the patch?
| |
| :
| |
| : Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
| |
| :
| |
| : Which older supported branches are affected by this flaw?
| |
| :
| |
| : If not all supported branches, which bug introduced the flaw?
| |
| :
| |
| : Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
| |
| :
| |
| : How likely is this patch to cause regressions; how much testing does it need?
| |
| | |
| This is similar to the ESR approval nomination form and is meant to help us evaluate the risks around approving the patch for checkin.
| |
| | |
| When the bug is approved for landing, the sec-approval flag will be set to '+' with a comment from the approver to land the patch. At that point, land it.
| |
| | |
| This will allow us to control when we can land security bugs without exposing them too early and to make sure they get landed on the various branches.
| |
| | |
| The security assurance team and release management will have their own process for approving bugs:
| |
| | |
| # The Security assurance team goes through sec-approval ? bugs daily and approves low risk fixes for central (if early in cycle). Developers can also ping the Security Assurance Team (specifically Al Billings & Dan Veditz) in #security on IRC when important.
| |
| # if the requestee or others have identified the regressing bug, add "regression" keyword and put the bug in the "blocks" field.
| |
| # Security team marks tracking flags to ? for all affected versions when approved for central. (This allows release management to decide whether to uplift to branches just like always.)
| |
| # Weekly security/release management triage meeting goes through sec-approval + and ? bugs where beta and ESR is affected, ? bugs with higher risk (sec-high and sec-critical), or ? bugs near end of cycle.
| |