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