1Fixing Security Bugs 2==================== 3 4A bug has been reported as security-sensitive in Bugzilla and received a 5security rating. 6 7If this bug is private - which is most likely for a reported security 8bug - **the process for patching is slightly different than the usual 9process for fixing a bug**. 10 11Here are security guidelines to follow if you’re involved in reviewing, 12testing and landing a security patch. See 13:ref:`Security Bug Approval Process` 14for more details about how to request sec-approval and land the patch. 15 16Keeping private information private 17----------------------------------- 18 19A security-sensitive bug in Bugzilla means that all information about 20the bug except its ID number are hidden. This includes the title, 21comments, reporter, assignee and CC’d people. 22 23A security-sensitive bug usually remains private until a fix is shipped 24in a new release, **and after a certain amount of time to ensure that a 25maximum number of users updated their version of Firefox**. Bugs are 26usually made public after 6 months and a couple of releases. 27 28From the moment a security bug has been privately reported to the moment 29a fix is shipped and the bug is set public, all information about that 30bug need to be handled carefully in order to avoid an unmitigated 31vulnerability to be known and exploited out there before we release a 32fix (0-day). 33 34During a normal process, information about the nature of bug can be 35accessed through: 36 37- Bug comments (Bugzilla, GitHub issue) 38- Commit message (visible on Bugzilla, tree check-ins and test servers) 39- Code comments 40- Test cases 41- Bug content can potentially be discussed on public IRC/Slack channels 42 and mailing list emails. 43 44When patching for a security bug, you’ll need to be mindful about what 45type of information you share and where. 46 47In commit messages 48~~~~~~~~~~~~~~~~~~ 49 50People are watching code check-ins, so we want to avoid sharing 51information which would disclose or help finding a vulnerability too 52easily before we shipped the fix to our users. This includes: 53 54- The **nature of the vulnerability** (overflow, use-after-free, XSS, 55 CSP bypass...) 56- **Ways to trigger and exploit that vulnerability** 57 - In commit messages, code comments and test cases. 58- The fact that a bug / commit is security-related: 59 60 - **Trigger words** in the commit message or code comments such as "security", "exploitable" or the nature of a security vulnerability (overflow, use-after-free…) 61 - **Security approver’s name** in a commit message. 62- The Firefox versions and components affected by the vulnerability. 63- Patches with an obvious fix. 64 65In Bugzilla and other public channels 66~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 67 68In addition to commits, you’ll need to be mindful of not disclosing 69sensitive information about the bug in public places, such as Bugzilla: 70 71- **Do not add public bugs in the “duplicate”, “depends on”, “blocks” 72 or “see also” section if these bugs could give hints about the nature 73 of the security issue.** 74 75 - Mention the bugs in comment of the private bug instead. 76- Do not comment sensitive information in public related bugs. 77- Also be careful about who you give bug access to: **double check 78 before CC’ing the wrong person or alias**. 79 80On IRC, Slack channels, GitHub issues, mailing lists: If you need to 81discuss about a security bug, use a private channel (protected with a 82password or with proper right access management) 83 84During Development 85------------------ 86 87Testing sec-high and sec-critical bugs 88~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89 90Pushing to Try servers requires Level 1 Commit access but **content 91viewing is publicly accessible**. 92 93As much as possible, **do not push to Try servers**. Testing should be 94done locally before checkin in order to prevent public disclosing of the 95bug. 96 97If you need to push to Try servers, make sure your tests don’t disclose 98what the vulnerability is about or how to trigger it. Do not mention 99anywhere it is security related. 100 101Obfuscating a security patch 102~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103 104If your security patch looks obvious because of the code it contains 105(e.g. a one-line fix), or if you really need to push to Try servers, 106**consider integrating your security-related patch to non-security work 107in the same area**. And/or pretend it is related to something else, like 108some performance improvement or a correctness fix. **Definitely don't 109include the bug number in the commit message.** This will help making 110the security issue less easily identifiable. (The absolute ban against 111"Security through Obscurity" is in relation to cryptographic systems. In 112other situations you still can't *rely* on obscurity but it can 113sometimes buy you a little time. In this context we need to get the 114fixes into the hands of our users faster than attackers can weaponize 115and deploy attacks and a little extra time can help.) 116 117Requesting sec-approval 118~~~~~~~~~~~~~~~~~~~~~~~ 119 120See :ref:`Security Bug Approval Process` 121for more details 122 123Landing tests 124~~~~~~~~~~~~~ 125 126Tests can be landed **after the release has gone live** and **not before 127at least 4 weeks following that release**. 128 129The exception is if a security issue has never been shipped in a release 130build and has been fixed in all development branches. 131 132Making a security bug public 133~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 134 135This is the responsibility of the security management team. 136 137Essentials 138---------- 139 140- **Do not disclose any information about the vulnerability before a 141 release with a fix has gone live for enough time for users to update 142 their software**. 143 144 - This includes code comments, commit messages, tests, public 145 communication channels. 146 147- If any doubt: '''request sec-approval? ''' 148- If any doubt: **needinfo security folks**. 149- **If there’s no rating, assume the worst and treat the bug as 150 sec-critical**. 151 152Documentation & Contacts 153------------------------ 154 155- :ref:`Normal process for submitting a patch <How to submit a patch>` 156- `How to file a security bug <https://wiki.mozilla.org/Security/Fileabug>`__ 157- `Handling Mozilla security bugs (policy) <https://www.mozilla.org/en-US/about/governance/policies/security-group/bugs/>`__ 158- `Security Bug Approval Process <security-approval>`__ 159- `Contacting the Security team(s) at Mozilla: <https://wiki.mozilla.org/Security>`__ 160