https://wiki.mozilla.org/api.php?action=feedcontributions&user=Tritter&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T11:15:14ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1246066Security/Firefox/Security Bug Life Cycle/Security Advisories2023-04-07T15:08:06Z<p>Tritter: /* Get review */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* ASAN Nightly bugs go into the roll-up advisory.<br />
* Sometimes we know a large library update will fix vulnerabilities, but we don't know _which_ vulnerabilities it fixes (often upstream does not assign CVEs, and we aren't allowed to assign CVEs for them) or if there are vulnerabilities at all (but we suspect there are.) We try to avoid this, but in these cases, it's acceptable to issue a CVE with details like e.g. 'Angle graphics library out of date' - 'An out of date graphics library (Angle) [likely] contained vulnerabilities that could potentially be exploited.'<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the roll-up<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects in the advisory description should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that '''issues that already have had a CVE assigned''' - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter. This is very important. It is common (usually several times a year) for us to request Google to assign a CVE for an issue in an upstream library. The Googler to contact for this is Adrian Taylor, and Tom Ritter (among others) can put you in touch.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! or Oh no, Google never got back to me! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number (like MFSA-TMP-2023-001). Everything will work fine. Later when we have the CVE, go back and assign it. It's hard to keep track of TMP numbers, but this is uncommon. A command like <code>git grep "MFSA-TMP" $(git rev-list --all -- announce) -- announce/</code> will show you any uses, even if they've been correct in the file.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So for now on we use the MFSA-TMP prefix to distinguish. We also previously used the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with your reviewer (you should know who that is, if you don't, ask) ahead of time when they will be able to review, and make sure you have the yml files ready by that time.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''If the release is on a Tuesday, this should be done no later than Friday evening.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1246065Security/Firefox/Security Bug Life Cycle/Security Advisories2023-04-07T15:06:39Z<p>Tritter: /* Assign CVEs */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* ASAN Nightly bugs go into the roll-up advisory.<br />
* Sometimes we know a large library update will fix vulnerabilities, but we don't know _which_ vulnerabilities it fixes (often upstream does not assign CVEs, and we aren't allowed to assign CVEs for them) or if there are vulnerabilities at all (but we suspect there are.) We try to avoid this, but in these cases, it's acceptable to issue a CVE with details like e.g. 'Angle graphics library out of date' - 'An out of date graphics library (Angle) [likely] contained vulnerabilities that could potentially be exploited.'<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the roll-up<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects in the advisory description should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that '''issues that already have had a CVE assigned''' - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter. This is very important. It is common (usually several times a year) for us to request Google to assign a CVE for an issue in an upstream library. The Googler to contact for this is Adrian Taylor, and Tom Ritter (among others) can put you in touch.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! or Oh no, Google never got back to me! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number (like MFSA-TMP-2023-001). Everything will work fine. Later when we have the CVE, go back and assign it. It's hard to keep track of TMP numbers, but this is uncommon. A command like <code>git grep "MFSA-TMP" $(git rev-list --all -- announce) -- announce/</code> will show you any uses, even if they've been correct in the file.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So for now on we use the MFSA-TMP prefix to distinguish. We also previously used the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1246064Security/Firefox/Security Bug Life Cycle/Security Advisories2023-04-07T14:57:58Z<p>Tritter: /* Background */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* ASAN Nightly bugs go into the roll-up advisory.<br />
* Sometimes we know a large library update will fix vulnerabilities, but we don't know _which_ vulnerabilities it fixes (often upstream does not assign CVEs, and we aren't allowed to assign CVEs for them) or if there are vulnerabilities at all (but we suspect there are.) We try to avoid this, but in these cases, it's acceptable to issue a CVE with details like e.g. 'Angle graphics library out of date' - 'An out of date graphics library (Angle) [likely] contained vulnerabilities that could potentially be exploited.'<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the roll-up<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects in the advisory description should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number. Everything will work fine. Later when we have the CVE, go back and assign it.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So I'm suggesting the MFSA-TMP prefix to distinguish. We also previously the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security_Severity_Ratings/Client&diff=1245667Security Severity Ratings/Client2023-03-01T18:22:41Z<p>Tritter: Add csectype-sandbox-escape</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we believe a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Sandbox escapes<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Private Browsing Mode data leaks<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through efficient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
* Most Denial of Service vulnerabilities, such as those requiring a browser restart<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-ssandbox-escape || A content process can cause memory corruption or arbitrary/JS code execution in any other process through malformed or tricky IPC messages or Shared Memory<br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== secopstype- Keywords ===<br />
<br />
secopstype- keywords are assigned to bugs to indicate the type of a client or website vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|secops-cred-leak || Issues relating to credentials leak of Mozilla related accounts<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Mobile/GeckoView&diff=1245388Mobile/GeckoView2023-02-02T20:22:35Z<p>Tritter: Add some security-relevant information</p>
<hr />
<div>'''GeckoView''' wraps Mozilla's [https://wikipedia.org/wiki/Gecko_(software) Gecko browser engine] in a reusable Android library for applications that wish to use Mozilla’s JavaScript, HTML layout, and rendering engines (generally referred to as SpiderMonkey and Gecko).<br />
<br />
Mozilla uses GeckoView to power [https://www.mozilla.org/en-US/firefox/browsers/mobile/android/ Firefox for Android], [https://blog.mozilla.org/blog/2018/09/18/firefox-reality-now-available/ Firefox Reality], [https://www.mozilla.org/firefox/mobile/#focus Firefox Focus], and other Android apps. GeckoView serves a similar purpose to Android's built-in WebView, but it has its own APIs and is ''not'' a drop in replacement.<br />
<br />
== Why GeckoView? ==<br />
<br />
While Android offers a built-in WebView, it's not intended for building browsers, and many advanced Web APIs are disabled. Android's WebView is also a moving target: it's impossible know exactly which engine (and what version of that engine) will power a WebView on client devices.<br />
<br />
In contrast, GeckoView is:<br />
<br />
* '''Full-Featured''': GeckoView is designed to expose the entire power of the Web to applications, including being suitable for building web browsers.<br />
* '''Self-Contained''': Because GeckoView is a standalone library that you bundle with your application, you can be confident that the code you test is the code that will actually run.<br />
* '''Standards Compliant''': Like Firefox, GeckoView offers excellent support for modern Web standards.<br />
<br />
== About GeckoView ==<br />
<br />
Mozilla provides a GeckoView package and a [https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/ Maven Repo] along with [https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/package-summary.html package documentation]. GeckoView has Stable, Beta, and Nightly channels that follow the [https://wiki.mozilla.org/Release_Management/Calendar Firefox browser’s Release Calendar] which typically ships a new major version to the Stable channel every 4 weeks and the maven repository is updated accordingly.<br />
<br />
When a new version is released to the Stable channel, any relevant security fixes will be published to the [https://www.mozilla.org/en-US/security/advisories/ Mozilla Security Advisories page]. While GeckoView is not explicitly called out in the advisories, most but not strictly all vulnerabilities will affect GeckoView. Exceptions would be vulnerabilities that occur in user-facing components excluded from GeckoView (such as the address bar) or desktop-platform-specific vulnerabilities. Keeping the GeckoView dependency up-to-date is the most effective way to incorporate security fixes.<br />
<br />
== Getting Help ==<br />
<br />
Interested in GeckoView? We're here to help!<br />
<br />
If you have questions or need assistance, please reach out to us in the [https://chat.mozilla.org/#/room/#geckoview:mozilla.org #geckoview] Matrix room.<br />
<br />
The overall Mozilla security team can be reached at security@mozilla.org. If you ship GeckoView in your application you are encouraged to let us know at that address.<br />
<br />
== Get Started ==<br />
<br />
''Building a browser? Check out [https://mozilla-mobile.github.io/android-components/ Android Components], our collection of ready-to-use support libraries!''<br />
<br />
=== Configure Gradle ===<br />
<br />
'''1. Set the GeckoView version'''<br />
<br />
''Like Firefox, GeckoView has three release channels: Stable, Beta, and Nightly. Browse the [https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/ Maven Repository] to see currently available builds.<br />
<syntaxhighlight lang="Groovy"><br />
ext {<br />
geckoviewChannel = "nightly"<br />
geckoviewVersion = "70.0.20190712095934"<br />
}<br />
</syntaxhighlight><br />
<br />
'''2. Add Mozilla's Maven repository'''<br />
<syntaxhighlight lang="Groovy"><br />
repositories {<br />
maven {<br />
url "https://maven.mozilla.org/maven2/"<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
'''3. Configure Java 8 support'''<br />
<br />
<syntaxhighlight lang="Groovy"><br />
android {<br />
// ...<br />
<br />
// Note: compileOptions is only required for minSdkVersion < 24<br />
compileOptions {<br />
sourceCompatibility JavaVersion.VERSION_1_8<br />
targetCompatibility JavaVersion.VERSION_1_8<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
'''4. Add GeckoView Implementations'''<br />
<syntaxhighlight lang="Groovy"><br />
dependencies {<br />
// ...<br />
implementation "org.mozilla.geckoview:geckoview-${geckoviewChannel}:${geckoviewVersion}" <br />
}<br />
</syntaxhighlight><br />
<br />
=== Add GeckoView to a Layout ===<br />
<br />
Inside a layout <code>.xml</code> file, add the following:<br />
<syntaxhighlight lang="XML"><br />
<org.mozilla.geckoview.GeckoView<br />
android:id="@+id/geckoview"<br />
android:layout_width="fill_parent"<br />
android:layout_height="fill_parent" /><br />
</syntaxhighlight><br />
<br />
=== Initialize GeckoView in an Activity ===<br />
<br />
'''1. Import the GeckoView classes inside an Activity:'''<br />
<syntaxhighlight lang="Java"><br />
import org.mozilla.geckoview.GeckoRuntime;<br />
import org.mozilla.geckoview.GeckoSession;<br />
import org.mozilla.geckoview.GeckoView;<br />
</syntaxhighlight><br />
<br />
'''2. In that activity's <code>onCreate</code> function, add the following:'''<br />
<syntaxhighlight lang="Java"><br />
GeckoView view = findViewById(R.id.geckoview);<br />
GeckoSession session = new GeckoSession();<br />
GeckoRuntime runtime = GeckoRuntime.create(this);<br />
<br />
session.open(runtime);<br />
view.setSession(session);<br />
session.loadUri("about:buildconfig"); // Or any other URL...<br />
</syntaxhighlight><br />
<br />
=== You're done! ===<br />
<br />
Your application should now load and display a webpage inside of GeckoView.<br />
<br />
To learn more about GeckoView's capabilities, review GeckoView's [https://mozilla.github.io/geckoview/javadoc/mozilla-central/ JavaDoc] or the [https://searchfox.org/mozilla-central/source/mobile/android/geckoview_example reference application].<br />
<br />
== Documentation and Examples ==<br />
<br />
'''APIs'''<br />
* [https://mozilla.github.io/geckoview/javadoc/mozilla-central/ GeckoView API Documentation] (JavaDoc format)<br />
* [https://mozilla-mobile.github.io/android-components/reference/ Android Components APIs]<br />
<br />
'''Building / Contributing'''<br />
<br />
* [https://mozilla.github.io/geckoview/contributor/geckoview-quick-start GeckoView Contributor Quick Start Guide].<br />
* [[Mobile/Get_Involved]]<br />
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction Mozilla Developer Guide]<br />
<br />
'''Bugs'''<br />
<br />
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=GeckoView&component=General File a new GeckoView bug]<br />
* [https://bugzilla.mozilla.org/buglist.cgi?product=GeckoView&component=General&resolution=---&list_id=14532935 All GeckoView Bugs]<br />
* [[Mobile/GeckoView/Bugs|GeckoView Bug Dashboard]] 🐛<br />
<br />
'''Products / Examples'''<br />
* [https://blog.mozilla.org/futurereleases/2019/06/27/reinventing-firefox-for-android-a-preview/ Firefox Preview] ([https://github.com/mozilla-mobile/fenix GitHub])<br />
* [https://blog.mozilla.org/blog/2018/09/18/firefox-reality-now-available/ Firefox Reality] ([https://github.com/mozillareality/firefoxreality GitHub])<br />
* [https://www.mozilla.org/firefox/mobile/#focus Firefox Focus] ([https://github.com/mozilla-mobile/focus-android/ GitHub])<br />
* [https://searchfox.org/mozilla-central/source/mobile/android/geckoview_example GeckoView Reference Application]<br />
<br />
'''Minimum System Requirements'''<br />
<br />
* GeckoView requires Android OS version 4.1 (API Level 16) or later. Fenix and Focus support Android 5.0 (API level 21) and later.<br />
* 32-bit ARMv7-A, 64-bit ARMv8-A (aka ARM64), 32-bit x86, or x86_64 CPU<br />
* Minimum device specs are quad-core 1.2 GHz and 2 GB RAM (like the [https://www.gsmarena.com/compare.php3?&idPhone3=8104&idPhone2=8721&idPhone1=9008 Moto G4 Play, E4, or E5]), though Mozilla's GeckoView test devices are the [https://en.wikipedia.org/wiki/Moto_G5 Moto G5] with an octa-core 1.4 GHz CPU and 2 GB RAM and the [https://en.wikipedia.org/wiki/Pixel_2 Google Pixel 2] with an octa-core 1.9 GHz CPU and 4 GB RAM.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1244826Security/Firefox/Security Bug Life Cycle/Security Advisories2022-12-08T16:25:27Z<p>Tritter: /* Criteria */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* ASAN Nightly bugs go into the roll-up advisory.<br />
* Sometimes we know a large library update will fix vulnerabilities, but we don't know _which_ vulnerabilities it fixes (often upstream does not assign CVEs, and we aren't allowed to assign CVEs for them) or if there are vulnerabilities at all (but we suspect there are.) We try to avoid this, but in these cases, it's acceptable to issue a CVE with details like e.g. 'Angle graphics library out of date' - 'An out of date graphics library (Angle) [likely] contained vulnerabilities that could potentially be exploited.'<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the roll-up<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number. Everything will work fine. Later when we have the CVE, go back and assign it.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So I'm suggesting the MFSA-TMP prefix to distinguish. We also previously the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1244825Security/Firefox/Security Bug Life Cycle/Security Advisories2022-12-08T16:22:45Z<p>Tritter: </p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* ASAN Nightly bugs go into the roll-up advisory.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the roll-up<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number. Everything will work fine. Later when we have the CVE, go back and assign it.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So I'm suggesting the MFSA-TMP prefix to distinguish. We also previously the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1243118Security/Firefox/Security Bug Life Cycle/Security Advisories2022-06-24T15:27:07Z<p>Tritter: /* Assign CVEs */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons. This can lead to a use-after-free causing a potentially exploitable crash.<br />
<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities.<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* The title should be a full sentence.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags.<br />
* Description of the bug should not credit/mention the bug reporter again.<br />
* Check the ESR version number for decimal errors (e.g., 78.6000001).<br />
* Do not include IRC nicks in the reporter field.<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'.<br />
* Check if there are no community members on the rollup, and if so, remove that bit.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. This can be automated with this script: https://github.com/tomrittervg/secadv/blob/master/cve_assignment_script.txt<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number. Everything will work fine. Later when we have the CVE, go back and assign it.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So I'm suggesting the MFSA-TMP prefix to distinguish. We also previously the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=MozillaBuild&diff=1242011MozillaBuild2022-04-21T20:29:59Z<p>Tritter: </p>
<hr />
<div>=== Overview ===<br />
MozillaBuild is a meta-installer that provides everything needed to build Mozilla on Windows, sans Visual C++. Its source lives in https://hg.mozilla.org/mozilla-build/. Bugs should be filed in [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=MozillaBuild mozilla.org :: MozillaBuild]. For information about building Mozilla on Win32, [https://firefox-source-docs.mozilla.org/setup/windows_build.html#building-firefox-on-windows see the Firefox Source Docs page].<br />
<br />
=== Current Version ===<br />
The current version of MozillaBuild is 4.0. It is available on [https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe ftp.mozilla.org].<br />
<br />
=== To Upgrade From A Previous Version ===<br />
<br />
Upgrading from an earlier MozillaBuild installation is straightforward but each step is important.<br />
<br />
# Delete your current MozillaBuild environment by moving your MozillaBuild folder into the trash. If you can't remove the existing installation, you probably have a terminal open or watchman or ssh-agent running. Terminate that process and try again.<br />
# Install the new MozillaBuild release. <br />
# If you had previously enabled Mintty, you will need to do so again by adding <tt>SET USE_MINTTY=1</tt> to the top of start-shell.bat.<br />
# Clobber any trees you have by running <tt>./mach clobber</tt> (<b>build errors may occur otherwise</b>).<br />
# Re-run <tt>./mach bootstrap</tt> to ensure that your tools are up-to-date. Ensure that you agree to run the Mercurial configuration wizard to ensure that its extensions are up-to-date.<br />
<br />
=== Windows Terminal ===<br />
<br />
It's possible to use Windows Terminal instead of the Command Prompt when using MozillaBuild.<br />
To do so, add the following profile to the Windows Terminal settings JSON file:<br />
<br />
{<br />
"name": "MozillaBuild",<br />
"commandline": "C:/mozilla-build/start-shell.bat -here",<br />
}<br />
<br />
Note that:<br />
* The <code>-here</code> flag can only be provided for MozillaBuild 4.0 and newer. Remove it from <code>commandline</code> if you're using MozillaBuild 3.4 or earlier.<br />
* Additionally, [https://bugzilla.mozilla.org/show_bug.cgi?id=1748762 the <code>"startingDirectory"</code> option and the <code>wt -d</code> flag don't work] unless <code>-here</code> is provided.<br />
<br />
<br />
=== Technical Details ===<br />
The MozillaBuild package contains other software prerequisites necessary for building Mozilla, including [https://www.msys2.org/ an MSYS2 environment], <br />
[https://www.mercurial-scm.org/ <code>Mercurial</code>], Python, NSIS, and UPX, as well as optional but useful tools such as wget and emacs.<br />
Note that the "UNIX-like" environment provided by MozillaBuild is only really useful for building and committing to the Mozilla source. Many command line tools you would expect in a modern Linux distribution are not present, and it's not possible to install them with a package manager.<br />
<br />
MozillaBuild does not modify the Windows registry.<br />
<br />
===== Command Prompt Tips and Caveats =====<br />
* To paste into this window, you must right-click on the window's title bar, move your cursor to the “Edit” menu, and click “Paste”. You can also set “Quick Edit Mode” in the “Properties” menu and right-click the window to paste your selection.<br />
* The MSYS2 root directory is located at<code>/c/mozilla-build/msys2/</code> (assuming the default installation directory).<br />
** For MozillaBuild 3.4 and older, the MSYS root directory can be found at <code>/c/mozilla-build/msys/</code> instead.<br />
* As of MozillaBuild 4.0, [https://cygwin.com/cygwin-ug-net/cygpath.html <code>cygpath</code>] can be used to convert between path types:<br />
<br />
To convert from a Windows path to a Unix-y one, such as using MozillaBuild to edit a file printed by <code>hg</code> (<b>remember to use single-quotes here!</b>)<br />
<br />
$ cygpath -u 'C:\mozilla-source\mozilla-unified\README.txt'<br />
/c/mozilla-source/mozilla-unified/README.txt<br />
<br />
To convert from a Unix-y path to a Windows one, such as for copying a path printed by MozillaBuild to open in your Windows-native IDE:<br />
<br />
$ cygpath -w '/c/mozilla-source/mozilla-unified/README.txt'<br />
C:\mozilla-source\mozilla-unified\README.txt<br />
<br />
=== Release Notes ===<br />
* [https://groups.google.com/a/mozilla.org/g/dev-platform/c/0GHhML7tY6c MozillaBuild 4.0]<br />
* [https://groups.google.com/a/mozilla.org/g/dev-platform/c/MzWYQ0NtXos MozillaBuild 3.4]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/oQk9k9-co54/k5FaAMg2BwAJ MozillaBuild 3.3]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/yJY5Ra0vJLQ/SsK9O-eoDgAJ MozillaBuild 3.2]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/Hy-LPWqJxd8/N1-AzRfhBAAJ MozillaBuild 3.1.1]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/C_S6HXcz7g0/6fIcnCF8BQAJ MozillaBuild 3.1]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/goLGqnPfAMI/-79pncxxBwAJ MozillaBuild 3.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/j4MUKzoDOlQ/gHH7w495AgAJ MozillaBuild 2.2.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/qpO21XQaNV8/-D5mNKqnCAAJ MozillaBuild 2.1.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/xJjMtp1_GV0/-zVzSMuDNVcJ MozillaBuild 2.0.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/XnFg0p1DJVI/laRQeGJDviwJ MozillaBuild 1.11.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/rslz21w1vng/P0jvA5y4vL4J MozillaBuild 1.10.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/cUqsdWEWIcw/HDyhJMz3-ysJ MozillaBuild 1.9.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/_9U6160_oyA/dWWpklVicwkJ MozillaBuild 1.8.0]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/XRecAHF-H28/aSbrdKJLUNoJ MozillaBuild 1.7]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/J3sBNBU1SvY/THhkqOCAvvYJ MozillaBuild 1.6]<br />
* [https://groups.google.com/d/msg/mozilla.dev.platform/s7PsRYJyHbI/AsLz9dVgwIUJ MozillaBuild 1.5.1]: added YASM for WebM code in Firefox 4.<br />
* [http://blog.mozilla.com/ted/2010/07/22/mozillabuild-1-5/ MozillaBuild 1.5]: Mercurial 1.5.4, Python 2.6.5, and support for Visual Studio 2010.<br />
* [http://blog.mozilla.com/ted/2009/07/24/mozillabuild-1-4/ MozillaBuild 1.4]: Windows x64 compatibility and other.<br />
* [http://blog.mozilla.com/ted/2008/06/16/mozillabuild-13/ MozillaBuild 1.3]<br />
* [[MozillaBuild:ReleaseNotes:1.2]]<br />
<br />
There are no release notes for 1.1 and below.<br />
<br />
=== Historic Versions ===<br />
Old versions of MozillaBuild can also be found on [https://ftp.mozilla.org/pub/mozilla/libraries/win32/ ftp.mozilla.org].</div>Tritterhttps://wiki.mozilla.org/index.php?title=Release_Management/Calendar&diff=1238094Release Management/Calendar2021-09-23T16:20:21Z<p>Tritter: Add fxtrains heroku link</p>
<hr />
<div>{{DISPLAYTITLE:Firefox Release Calendar}}<br />
This schedule is based on the current [[RapidRelease]] plan. Future dates may change if the process changes. Code is not always released to users on the same day as the branch migration. The release to users may be a few days later, to allow for manual testing and sign-off. Thunderbird tracks the [https://www.mozilla.org/en-US/firefox/organizations/ ESR schedule] column per [[Thunderbird:Home#Releases|Thunderbird release info]].<br />
<br />
== Calendars ==<br />
<br />
This wiki page may not always have the most current information. Please refer to one of the following calendars for up-to-date scheduling:<br />
<br />
* [https://www.google.com/calendar/embed?src=mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com Firefox Merge/Release Dates] ([https://www.google.com/calendar/ical/mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com/public/basic.ics ICS for Thunderbird/Lightning or your calendar app]) (low noise)<br />
* [https://www.google.com/calendar/embed?src=bW96aWxsYS5jb21fZGJxODRhbnI5aTh0Y25taGFiYXRzdHY1Y29AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Firefox Merge/Release Full Scheduling Calendar] ([https://calendar.google.com/calendar/ical/mozilla.com_dbq84anr9i8tcnmhabatstv5co%40group.calendar.google.com/public/basic.ics ICS]) (highly detailed - 99.99% up to date)<br />
<br />
== Future branch dates ==<br />
<big>[[Release_Management/Release_owners|Release Owners]]</big><br />
{| class="wikitable"<br />
|-<br />
!Quarter ||Soft Freeze ||Merge Date ||Nightly ||Beta ||Release Date ||Release ||ESR<br />
|-<br />
|rowspan="3"|Q4 2021<br />
!2021-09-30<br />
!2021-10-04<br />
|[https://fx-trains.herokuapp.com/release/?version=95 Firefox 95]||[https://fx-trains.herokuapp.com/release/?version=94 Firefox 94]<br />
!2021-10-05<br />
|Firefox 93<br />
|Firefox 78.15; 91.2<br />
|-<br />
!2021-10-28<br />
!2021-11-01<br />
|[https://fx-trains.herokuapp.com/release/?version=96 Firefox 96]||[https://fx-trains.herokuapp.com/release/?version=95 Firefox 95]<br />
!2021-11-02<br />
|Firefox 94<br />
|Firefox 91.3<br />
|-<br />
!2021-12-02<br />
!2021-12-06<br />
|[https://fx-trains.herokuapp.com/release/?version=97 Firefox 97]||[https://fx-trains.herokuapp.com/release/?version=96 Firefox 96]<br />
!2021-12-07<br />
|Firefox 95<br />
|Firefox 91.4<br />
|-<br />
|rowspan="3"|Q1 2022<br />
!2022-01-06<br />
!2022-01-10<br />
|[https://fx-trains.herokuapp.com/release/?version=98 Firefox 98]||[https://fx-trains.herokuapp.com/release/?version=97 Firefox 97]<br />
!2022-01-11<br />
|Firefox 96<br />
|Firefox 91.5<br />
|-<br />
!2022-02-03<br />
!2022-02-07<br />
|[https://fx-trains.herokuapp.com/release/?version=99 Firefox 99]||[https://fx-trains.herokuapp.com/release/?version=98 Firefox 98]<br />
!2022-02-08<br />
|Firefox 97<br />
|Firefox 91.6<br />
|-<br />
!2022-03-03<br />
!2022-03-07<br />
|[https://fx-trains.herokuapp.com/release/?version=100 Firefox 100]||[https://fx-trains.herokuapp.com/release/?version=99 Firefox 99]<br />
!2022-03-08<br />
|Firefox 98<br />
|Firefox 91.7<br />
|-<br />
|}<br />
<br />
<p>The Nightly soft freeze is typically during the week prior to merge day. During this period high-risk patches should avoid landing until after the Nightly version bump lands on mozilla-central on merge day.</p><br />
<br />
== Past branch dates ==<br />
More details on contents of releases can be found in the [https://www.mozilla.org/firefox/releases/ release notes archive] or [https://en.wikipedia.org/wiki/Firefox_version_history Wikipedia: Firefox version history].<br />
<br />
{| class="wikitable"<br />
|-<br />
!Soft Freeze||Merge Date||Central||Beta<br />
!Release Date||Release||ESR<br />
|-<br />
!2021-09-02<br />
!2021-09-06<br />
|Firefox 94||Firefox 93<br />
!2021-09-07<br />
|Firefox 92<br />
|Firefox 78.14; 91.1<br />
|-<br />
!2021-08-05<br />
!2021-08-09<br />
|Firefox 93||Firefox 92<br />
!2021-08-10<br />
|Firefox 91<br />
|Firefox 78.13; 91.0<br />
|-<br />
!2021-07-08<br />
!2021-07-12<br />
|Firefox 92||Firefox 91<br />
!2021-07-13<br />
|Firefox 90<br />
|Firefox 78.12<br />
|-<br />
!2021-05-27<br />
!2021-05-31<br />
|Firefox 91||Firefox 90<br />
!2021-06-01<br />
|Firefox 89<br />
|Firefox 78.11<br />
|-<br />
!2021-04-15<br />
!2021-04-19<br />
|Firefox 90||Firefox 89<br />
!2021-04-19<br />
|Firefox 88<br />
|Firefox 78.10<br />
|-<br />
!2021-03-18<br />
!2021-03-22<br />
|Firefox 89||Firefox 88<br />
!2021-03-23<br />
|Firefox 87<br />
|Firefox 78.9<br />
|-<br />
!2021-02-18<br />
!2021-02-22<br />
|Firefox 88||Firefox 87<br />
!2021-02-23<br />
|Firefox 86<br />
|Firefox 78.8<br />
|-<br />
!2021-01-21<br />
!2021-01-25<br />
|Firefox 87||Firefox 86<br />
!2021-01-26<br />
|Firefox 85<br />
|Firefox 78.7<br />
|-<br />
!2020-12-10<br />
!2020-12-14<br />
|Firefox 86||Firefox 85<br />
!2020-12-15<br />
|Firefox 84<br />
|Firefox 78.6<br />
|-<br />
!2020-11-12<br />
!2020-11-16<br />
|Firefox 85||Firefox 84<br />
!2020-11-17<br />
|Firefox 83<br />
|Firefox 78.5<br />
|-<br />
!2020-10-15<br />
!2020-10-19<br />
|Firefox 84||Firefox 83<br />
!2020-10-20<br />
|Firefox 82<br />
|Firefox 78.4<br />
|-<br />
!2020-09-17<br />
!2020-09-21<br />
|Firefox 83||Firefox 82<br />
!2020-09-22<br />
|Firefox 81<br />
|Firefox 78.3<br />
|-<br />
!2020-08-20<br />
!2020-08-24<br />
|Firefox 82||Firefox 81<br />
!2020-08-25<br />
|Firefox 80<br />
|Firefox 68.12; 78.2<br />
|-<br />
!2020-07-23<br />
!2020-07-27<br />
|Firefox 81||Firefox 80<br />
!2020-07-28<br />
|Firefox 79<br />
|Firefox 68.11; 78.1<br />
|-<br />
!2020-06-26<br />
!2020-06-29<br />
|Firefox 80||Firefox 79<br />
!2020-06-30<br />
|Firefox 78<br />
|Firefox 68.10; 78.0<br />
|-<br />
!2020-05-28<br />
!2020-06-01<br />
|Firefox 79||Firefox 78<br />
!2020-06-02<br />
|Firefox 77<br />
|Firefox 68.9<br />
|-<br />
!2020-04-30<br />
!2020-05-04<br />
|Firefox 78||Firefox 77<br />
!2020-05-05<br />
|Firefox 76<br />
|Firefox 68.8<br />
|-<br />
!2020-04-02<br />
!2020-04-06<br />
|Firefox 77||Firefox 76<br />
!2020-04-07<br />
|Firefox 75<br />
|Firefox 68.7<br />
|-<br />
!2020-03-05<br />
!2020-03-09<br />
|Firefox 76||Firefox 75<br />
!2020-03-10<br />
|Firefox 74<br />
|Firefox 68.6<br />
|-<br />
!2020-02-06<br />
!2020-02-10<br />
|Firefox 75||Firefox 74<br />
!2020-02-11<br />
|Firefox 73<br />
|Firefox 68.5<br />
|-<br />
!2020-01-02<br />
!2020-01-06<br />
|Firefox 74||Firefox 73<br />
!2020-01-07<br />
|Firefox 72<br />
|Firefox 68.4<br />
|-<br />
!2019-11-25<br />
!2019-12-02<br />
|Firefox 73||Firefox 72<br />
!2019-12-03<br />
|Firefox 71<br />
|Firefox 68.3<br />
|-<br />
!2019-10-14<br />
!2019-10-21<br />
|Firefox 72||Firefox 71<br />
!2019-10-22<br />
|Firefox 70<br />
|Firefox 68.2<br />
|-<br />
!2019-08-26<br />
!2019-09-02<br />
|Firefox 71||Firefox 70<br />
!2019-09-03<br />
|Firefox 69<br />
|Firefox 60.9; 68.1<br />
|-<br />
!2019-07-01<br />
!2019-07-08<br />
|Firefox 70||Firefox 69<br />
!2019-07-09<br />
|Firefox 68<br />
|Firefox 60.8; 68.0<br />
|-<br />
!2019-05-13<br />
!2019-05-20<br />
|Firefox 69||Firefox 68<br />
!2019-05-21<br />
|Firefox 67<br />
|Firefox 60.7<br />
|-<br />
!2019-03-11<br />
!2019-03-18<br />
|[https://docs.google.com/spreadsheets/d/1jtNuLGugHVgZTKR3NXQGngA_EjzSGxpRBzW-DvNK3EI/edit Firefox 68]||[https://docs.google.com/document/d/1feDkXleRXMJJS9lxP_vbyBApIDoEr44KchAZoYHkS54/edit Firefox 67]<br />
!2019-03-19<br />
|Firefox 66<br />
|Firefox 60.6<br />
|-<br />
!2019-01-21<br />
!2019-01-28<br />
|[https://docs.google.com/document/d/1feDkXleRXMJJS9lxP_vbyBApIDoEr44KchAZoYHkS54/edit Firefox 67]||Firefox 66<br />
!2019-01-29<br />
|Firefox 65<br />
|Firefox 60.5<br />
|-<br />
!2018-12-03<br />
!2018-12-10<br />
|[https://docs.google.com/document/d/1KnDiM3UmLbCPrc3UVZq6Z5Tdb2jnTfjpdyahSqgSGNE/edit Firefox 66]||Firefox 65<br />
!2018-12-11<br />
|Firefox 64<br />
|Firefox 60.4<br />
|-<br />
!2018-10-15<br />
!2018-10-22<br />
|[https://docs.google.com/document/d/1vI9KWvSMQ50R9YgdMX7nG7CSuOnTeRGN9sOH_D6_v_c/edit Firefox 65]||Firefox 64<br />
!2018-10-23<br />
|Firefox 63<br />
|Firefox 60.3<br />
|-<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
!Merge Date||Central||Beta<br />
!Release Date||Release||ESR<br />
|-<br />
!2018-09-04<br />
|[https://docs.google.com/document/d/1MQa4J9OSTc1i60sFcVNyoFNLK8TLBXJlL9W12VoEUAc/edit Firefox 64]||Firefox 63<br />
!2018-09-05<br />
|Firefox 62<br />
|Firefox 60.2<br />
|-<br />
!2018-06-25<br />
|[https://docs.google.com/document/d/185O88wIwV-fRwqOKJaCCPVXjxhm70h8J4ApsJt1H9Rk/edit Firefox 63]||Firefox 62<br />
!2018-06-26<br />
|Firefox 61<br />
|Firefox 52.9; 60.1<br />
|-<br />
!2018-05-07<br />
|[https://docs.google.com/document/d/17FvsBOudLr15DgN-E82UamLhnweDHmGzQu4wIEi1QUg/edit Firefox 62]||Firefox 61<br />
!2018-05-09<br />
|Firefox 60<br />
|Firefox 52.8; 60.0<br />
|-<br />
!2018-03-12<br />
|[https://docs.google.com/document/d/1cLYXPrlEES90PSKQHFLf3j0tiOUfUth2ye9Kfg9xLYY/edit Firefox 61]||Firefox 60<br />
!2018-03-13<br />
|Firefox 59<br />
|Firefox 52.7<br />
|-<br />
!2018-01-22<br />
|[https://docs.google.com/document/d/14D5Au23znkkqeLZu22cI7kSM0EowkC0cq0ppiZR2lg4/edit Firefox 60]||Firefox 59<br />
!2018-01-23<br />
|Firefox 58<br />
|Firefox 52.6<br />
|-<br />
!2017-11-13<br />
|[https://docs.google.com/document/d/1ZOs9Ingbz0e-mWDu8yXGiMM-SnpBXThkLdXnplG4e2w/edit Firefox 59]||Firefox 58<br />
!2017-11-14<br />
|Firefox 57<br />
|Firefox 52.5<br />
|-<br />
!2017-09-21<br />
|[https://docs.google.com/document/d/1jPyeW14MyHyQX7kXBU8KN9jsxO2VQjP3GN_VpLiG9YM/edit Firefox 58]||Firefox 57<br />
!2017-09-28<br />
|Firefox 56<br />
|Firefox 52.4<br />
|-<br />
!2017-08-02<br />
|[https://docs.google.com/document/d/1jeypuqBqEyIh-4qxXT0UnE2aVjetN7uVD8W7L7TbWKg/edit Firefox 57]||Firefox 56<br />
!2017-08-08<br />
|Firefox 55<br />
|Firefox 52.3<br />
|-<br />
!2017-06-12<br />
|Firefox 56||Firefox 55<br />
!2017-06-13<br />
|Firefox 54<br />
|Firefox 52.2<br />
|-<br />
!2017-04-18<br />
|Firefox 55||Firefox 54<br />
!2017-04-19<br />
|Firefox 53<br />
|Firefox 45.9; 52.1<br />
|-<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
!Merge Date||Central||Aurora||Beta<br />
!Release Date||Release||ESR<br />
|-<br />
!2017-03-06<br />
|Firefox 55||Firefox 54||Firefox 53<br />
!2017-03-07<br />
|Firefox 52<br />
|Firefox 45.8; 52.0<br />
|-<br />
!2017-01-23<br />
|Firefox 54||Firefox 53||Firefox 52<br />
!2017-01-24<br />
|Firefox 51<br />
|Firefox 45.7<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
!2016-12-13<br />
|Firefox 50.1.0<br />
|Firefox 45.6<br />
|-<br />
!2016-11-14<br />
|Firefox 53||Firefox 52||Firefox 51<br />
!2016-11-15<br />
|Firefox 50<br />
|Firefox 45.5<br />
|-<br />
!2016-09-19<br />
|Firefox 52||Firefox 51||Firefox 50<br />
!2016-09-20<br />
|Firefox 49<br />
|Firefox 45.4<br />
|-<br />
!2016-08-01<br />
|Firefox 51||Firefox 50||Firefox 49<br />
!2016-08-02<br />
|Firefox 48<br />
|Firefox 45.3<br />
|-<br />
!2016-06-06<br />
|Firefox 50||Firefox 49||Firefox 48<br />
!2016-06-07<br />
|Firefox 47<br />
|Firefox 45.2<br />
|-<br />
!2016-04-25<br />
|Firefox 49||Firefox 48||Firefox 47<br />
!2016-04-26<br />
|Firefox 46<br />
|Firefox 38.8; 45.1<br />
|-<br />
!2016-03-07<br />
|Firefox 48||Firefox 47||Firefox 46<br />
!2016-03-08<br />
|Firefox 45<br />
|Firefox 38.7; 45.0<br />
|-<br />
!2016-01-25<br />
|Firefox 47||Firefox 46||Firefox 45<br />
!2016-01-26<br />
|Firefox 44<br />
|Firefox 38.6<br />
|-<br />
!2015-12-14<br />
|Firefox 46||Firefox 45||Firefox 44<br />
!2015-12-15<br />
|Firefox 43<br />
|Firefox 38.5<br />
|-<br />
!2015-10-29<br />
|Firefox 45||Firefox 44||Firefox 43<br />
!2015-11-03<br />
|Firefox 42<br />
|Firefox 38.4<br />
|-<br />
!2015-09-21<br />
|Firefox 44||Firefox 43||Firefox 42<br />
!2015-09-22<br />
|Firefox 41<br />
|Firefox 38.3<br />
|-<br />
!2015-08-10<br />
|Firefox 43||Firefox 42||Firefox 41<br />
!2015-08-11<br />
|Firefox 40<br />
|Firefox 38.2<br />
|-<br />
!2015-06-29<br />
|Firefox 42||Firefox 41||Firefox 40<br />
!2015-06-30<br />
|Firefox 39<br />
|Firefox 31.8; 38.1<br />
|-<br />
!<br />
| || || <br />
!2015-06-02<br />
|Firefox 38.0.5<br />
|-<br />
!2015-05-11*<br />
|Firefox 41||Firefox 40||Firefox 39<br />
!2015-05-12*<br />
|Firefox 38<br />
|Firefox 31.7; 38.0<br />
|-<br />
!2015-03-30*<br />
|Firefox 40||Firefox 39||Firefox 38<br />
!2015-03-31*<br />
|Firefox 37<br />
|Firefox 31.6<br />
|-<br />
!2015-02-23<br />
|Firefox 39||Firefox 38||Firefox 37<br />
!2015-02-24<br />
|Firefox 36<br />
|Firefox 31.5<br />
|-<br />
!2015-01-12*<br />
|Firefox 38||Firefox 37||Firefox 36<br />
!2015-01-13*<br />
|Firefox 35<br />
|Firefox 31.4<br />
|-<br />
!2014-11-28*<br />
|Firefox 37||Firefox 36||Firefox 35<br />
!2014-12-01*<br />
|Firefox 34<br />
|Firefox 31.3<br />
|-<br />
!2014-10-13 <br />
|Firefox 36||Firefox 35||Firefox 34<br />
!2014-10-14<br />
|Firefox 33<br />
|Firefox 31.2<br />
|-<br />
!2014-09-02*<br />
|Firefox 35||Firefox 34||Firefox 33<br />
!2014-09-02<br />
|Firefox 32<br />
|Firefox 24.8; 31.1<br />
|-<br />
!2014-07-21<br />
|Firefox 34||Firefox 33||Firefox 32<br />
!2014-07-22<br />
|Firefox 31<br />
|Firefox 24.7; 31.0<br />
|-<br />
!2014-06-09<br />
|Firefox 33||Firefox 32||Firefox 31<br />
!2014-06-10<br />
|Firefox 30<br />
|Firefox 24.6<br />
|-<br />
!2014-04-28<br />
|Firefox 32||Firefox 31||Firefox 30<br />
!2014-04-29<br />
|Firefox 29<br />
|Firefox 24.5<br />
|-<br />
!2014-03-17<br />
|Firefox 31||Firefox 30||Firefox 29<br />
!2014-03-18<br />
|Firefox 28<br />
|Firefox 24.4<br />
|-<br />
!2014-02-03*<br />
|Firefox 30||Firefox 29||Firefox 28<br />
!2014-02-04*<br />
|Firefox 27<br />
|Firefox 24.3<br />
|-<br />
!2013-12-09<br />
|Firefox 29||Firefox 28||Firefox 27<br />
!2013-12-10<br />
|Firefox 26<br />
|Firefox 24.2<br />
|-<br />
!2013-10-28<br />
|Firefox 28||Firefox 27||Firefox 26<br />
!2013-10-29<br />
|Firefox 25<br />
|Firefox 17.0.10; 24.1<br />
|-<br />
!2013-09-16<br />
|Firefox 27||Firefox 26||Firefox 25<br />
!2013-09-17<br />
|Firefox 24<br />
|Firefox 17.0.9; 24.0<br />
|-<br />
!2013-08-05<br />
|Firefox 26||Firefox 25||Firefox 24<br />
!2013-08-06<br />
|Firefox 23<br />
|Firefox 17.0.8<br />
|-<br />
!2013-06-24<br />
|Firefox 25||Firefox 24||Firefox 23<br />
!2013-06-25<br />
|Firefox 22<br />
|Firefox 17.0.7<br />
|-<br />
!2013-05-13<br />
|Firefox 24||Firefox 23||Firefox 22<br />
!2013-05-14<br />
|Firefox 21<br />
|Firefox 17.0.6<br />
|-<br />
!2013-04-01<br />
|Firefox 23||Firefox 22||Firefox 21<br />
!2013-04-02<br />
|Firefox 20<br />
|Firefox 17.0.5<br />
|-<br />
!2013-02-19*<br />
|Firefox 22||Firefox 21||Firefox 20<br />
!2013-02-19<br />
|Firefox 19<br />
|Firefox 17.0.3<br />
|-<br />
!2013-01-07<nowiki>*</nowiki><br />
|Firefox 21||Firefox 20||Firefox 19<br />
!2013-01-08<nowiki>*</nowiki><br />
|Firefox 18<br />
|Firefox 10.0.12; 17.0.2<br />
|-<br />
!2012-11-19<br />
|Firefox 20||Firefox 19||Firefox 18<br />
!2012-11-20<br />
|Firefox 17<br />
|Firefox 10.0.11; 17.0<br />
|-<br />
!2012-10-08<br />
|Firefox 19<br />
|Firefox 18<br />
|Firefox 17<br />
!2012-10-09<br />
|Firefox 16<br />
|Firefox 10.0.8<br />
|-<br />
!2012-08-27<br />
|Firefox 18<br />
|Firefox 17<br />
|Firefox 16<br />
!2012-08-28<br />
|Firefox 15<br />
|Firefox 10.0.7<br />
|-<br />
!2012-07-16<br />
|Firefox 17<br />
|Firefox 16<br />
|Firefox 15<br />
!2012-07-17<br />
|Firefox 14<br />
|Firefox 10.0.6<br />
|-<br />
!2012-06-05<br />
|Firefox 16<br />
|Firefox 15<br />
|Firefox 14<br />
!2012-06-05<br />
|Firefox 13<br />
|Firefox 10.0.5<br />
|-<br />
!2012-04-24<br />
|Firefox 15<br />
|Firefox 14<br />
|Firefox 13<br />
!2012-04-24<br />
|Firefox 12<br />
|Firefox 10.0.4<br />
|-<br />
!2012-03-13<br />
|Firefox 14<br />
|Firefox 13<br />
|Firefox 12<br />
!2012-03-13<br />
|Firefox 11<br />
|Firefox 10.0.3<br />
|-<br />
!2012-01-31<br />
|Firefox 13<br />
|Firefox 12<br />
|Firefox 11<br />
!2012-01-31<br />
|Firefox 10<br />
|Firefox 10.0<br />
|-<br />
!2011-12-20<br />
|Firefox 12<br />
|Firefox 11<br />
|Firefox 10<br />
!2011-12-20<br />
|Firefox 9<br />
|-<br />
!2011-11-08<br />
|Firefox 11<br />
|Firefox 10<br />
|Firefox 9<br />
!2011-11-08<br />
|Firefox 8<br />
|-<br />
!2011-09-27<br />
|Firefox 10<br />
|Firefox 9<br />
|Firefox 8<br />
!2011-09-27<br />
|Firefox 7<br />
|-<br />
!2011-08-16<br />
|Firefox 9<br />
|Firefox 8<br />
|Firefox 7<br />
!2011-08-16<br />
|Firefox 6<br />
|-<br />
!2011-07-05<br />
|Firefox 8||Firefox 7||Firefox 6<br />
!<br />
|<br />
|-<br />
!<br />
| || || <br />
!2011-06-21<br />
|Firefox 5<br />
|-<br />
!2011-05-24<br />
|Firefox 7||Firefox 6|| <br />
|-<br />
!2011-05-17<br />
| || ||Firefox 5<br />
|-<br />
!2011-04-12<br />
|Firefox 6||Firefox 5 <br />
|-<br />
|}<br />
<br />
<nowiki>*</nowiki>Some release dates and merge dates are rescheduled to avoid conflicts with holidays.<br />
<br />
Notes:<br />
* Four week schedule starting late 2019.<br />
* Irregular schedule targeting six to eight week intervals, adjusting for holidays, starting 2016.<br />
* Six week schedule from 2011 to 2015 (with some dates delayed to avoid conflicts with holidays).<br />
* Firefox 5 was on a slightly different schedule. It spent five weeks each on Aurora and Beta while later releases spent six weeks on each branch.<br />
<br />
[[category:Release_Management|R]]</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1231013Security/Firefox/Security Bug Life Cycle/Security Advisories2020-09-22T15:36:06Z<p>Tritter: /* Assign CVEs */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'<br />
* Check if there are no community members on the rollup, and if so, remove that bit<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
==== Oh no, I don't have enough CVEs! ====<br />
<br />
That's alright. Assign the issue an id of MFSA-TMP-YEAR-#### where # is a unique incrementing number. Everything will work fine. Later when we have the CVE, go back and assign it.<br />
<br />
[https://github.com/mozilla/foundation-security-advisories/commit/3114d01de2f27cdb606d8d07603c2362515104f1 Here's an example of what it looks like.]<br />
<br />
n.b. While that example used MFSA-YEAR-####, that format is actually used for the advisories themselves (so MFSA-2020-0001 was accidentally used to refer both to an individual issue pending a CVE and to all advisories for Firefox 71.) So I'm suggesting the MFSA-TMP prefix to distinguish. We also previously the MFSA-YEAR-# format for individual issues from 2005ish - 2016.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. '''This should be done about 4 days before the release.'''<br />
<br />
=== Release ===<br />
<br />
Before releasing ensure that no last-days uplift happened that would be ommitted. The yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security_Severity_Ratings/Client&diff=1230404Security Severity Ratings/Client2020-08-27T18:15:18Z<p>Tritter: PBM leaks are moderate</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we believe a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Sandbox escapes<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Private Browsing Mode data leaks<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through efficient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
* Most Denial of Service vulnerabilities, such as those requiring a browser restart<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== secopstype- Keywords ===<br />
<br />
secopstype- keywords are assigned to bugs to indicate the type of a client or website vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|secops-cred-leak || Issues relating to credentials leak of Mozilla related accounts<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Hall_of_Fame&diff=1228400Security/Firefox/Security Bug Life Cycle/Hall of Fame2020-06-23T15:43:19Z<p>Tritter: Created page with "===== Updating the Client Bug Bounty Hall of Fame ===== The <u>Client</u> Bug Bounty Hall of Fame is located at https://www.mozilla.org/en-US/security/bug-bounty/hall-of-fame..."</p>
<hr />
<div>===== Updating the Client Bug Bounty Hall of Fame =====<br />
<br />
The <u>Client</u> Bug Bounty Hall of Fame is located at https://www.mozilla.org/en-US/security/bug-bounty/hall-of-fame/ This wiki page is about how to update it.<br />
<br />
The HOF lives in https://github.com/mozilla/foundation-security-advisories and the script to update it is there as well. Grab that repo.<br />
<br />
Using a bugzilla API key, run <br />
<br />
<pre>./update_hof.py -a <apikey> -y <year> -q <quarter> -f bug-bounty-hof/client.yml</pre><br />
<br />
It will remind you that you need to assign hof+ flags to bugs that should receive it. Kill the script, copy that link, go assign the flags, and then come back and re-run it.<br />
<br />
This will take a long time, because it needs to look at every security bug. When it's done, it will:<br />
<br />
# Prepend the new credit entries to the client.yml file<br />
# Edit the update_hof.py script to contain any new credit mappings that should be present<br />
# Produce a debuglog.&lt;timestamp>.log file.<br />
<br />
Next we're going to double check things. You should:<br />
* git diff the client.yml file looking for any unusual entries (e.g. 'Anonymous' or shared credit entries)<br />
* <tt>grep -v range debuglog.&lt;timestamp>.log</tt> to look at the bugs that resulted in credit entries. This allows you to map credit entries from the yml file to bugs for checking.<br />
* Review these bugs. <br />
** If you gave a hof+ flag to a bug, do you see it here? (It should have a 'bounty-' indicator.) <br />
** Do any of these bugs have a special credit field from the bug? A shared credit?<br />
** Are any of them marked "do not publish"? Double check they shouldn't be published.<br />
<br />
After that, commit it to a branch, push it (you can push the branch to the public repo), and submit a pull request for Dan or Tom to review.<br />
<br />
(If you want, you can run <tt>./update_hof.py --sort-credit-entries</tt> in a second commit and copy-paste replace the existing variables in the script to sort them nicely.)<br />
<br />
===== Special Note =====<br />
<br />
For really weird implementation purposes, in order to run this script, you need access to [https://bugzilla.mozilla.org/show_bug.cgi?id=1622495 Bug 1622495]. If you can't view that bug, you're not going to be able to run the script.<br />
<br />
===== Historical Note =====<br />
<br />
In early 2020 Tom re-generated the entire Client Hall of Fame from 2010 to 2019. It involved a lot of manual work, and porting names across that disappeared. There is a <tt>doitall</tt> option buried in the script. You should not use it. It will not produce a Hall of Fame that is identical to the one present - a lot of manual touch-ups had to be made. Going forward we should update it a quarter at a time.</div>Tritterhttps://wiki.mozilla.org/index.php?title=BMO/Bot_Registry&diff=1225470BMO/Bot Registry2020-03-26T02:40:24Z<p>Tritter: </p>
<hr />
<div>Some times you want a BMO account that is not a real person.<br />
That's okay -- in fact it is a good security measure!<br />
<br />
However this comes with some problems -- if we (the bmo admins) can't tell who owns a bot,<br />
and we have to make a decision that might break we have no way of informing the owner except<br />
to break it and wait to hear back. This list below is by no means mandatory, but if you fill it out,<br />
we can help avoid future breakages!<br />
<br />
If you include a link to the repo, things can be even smoother.<br />
<br />
If your bot misbehaves, we can tell you about it rather than just blocking it. <br />
<br />
== Bot Requirements ==<br />
<br />
All bot and automation users:<br />
<br />
* '''must''' have a `bots.tld` bugmail by 2020-06-30<br />
* '''must''' use the REST api by 2020-06-30<br />
* if they have elevated privileges must use a API key by 2020-06-30<br />
* '''should''' be listed in this registry ''unless'' there is a business reason not to list them publicly<br />
* when they modify bugs, they '''should''' leave a comment that the bug has been modified by a bot unless it does not make sense to<br />
<br />
== Bot List ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Bot Bugmail !! Owner Bugmail !! API (xmlrpc, jsonrpc, bzapi, or rest) !! Token or API Key!! Repo<br />
|-<br />
| pulsebot@bots.tld || mh+mozilla@glandium.org || rest || api-key || https://github.com/glandium/pulsebot/<br />
|-<br />
| treeherderbugbot@gmail.com || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || xmlrpc || Username/password || [https://github.com/github/github-services/blob/master/lib/services/bugzilla.rb GitHub's Bugzilla integration]<br />
|-<br />
| intermittent-bug-filer@mozilla.bugs || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || rest || api-key || https://github.com/mozilla/treeherder<br />
|-<br />
| orangefactor@bots.tld || auto-tools@moco || rest || api-key || https://hg.mozilla.org/automation/orangefactor/<br />
|-<br />
| webops-kanban@mozilla.bugs || atoll || Unknown || Token || <br />
|-<br />
| mozilla+bugcloser@davedash.com || Unknown || Unknown || Token (github) || Unknown<br />
|-<br />
| release-mgmt-analysis@mozilla.com || mcastelluccio@mozilla.com || rest || api-key || https://github.com/mozilla/bugbug/<br />
|-<br />
| release-mgmt-account-bot@mozilla.tld || cdenizet@mozilla.com || rest || api-key || https://github.com/mozilla/relman-auto-nag/<br />
|-<br />
| slaveapi@mozilla.releng.tld || release@mozilla.com || Unknown || Unknown || https://github.com/mozilla/build-slaveapi<br />
|-<br />
| flow2bugs@netops.bugs || unknown || Unknown || Unknown || Unknown<br />
|- <br />
| webcompat-bugs@mozilla.bugs || miket@mozilla.com || rest || api-key || TBD<br />
|-<br />
| pulgasaur@mozilla.bugs || peterbe@mozilla.com || rest || api-key || https://github.com/mozilla/github-bugzilla-pr-linker<br />
|-<br />
| moc-queue-bot@mozilla.bugs || moc@mozilla.com || rest || api-key || git-internal/puppet/modules/moc_bug_queuemon<br />
|-<br />
| omphalos@mozilla.bugs || mgoodwin@mozilla.com || rest || api-key || https://github.com/mozilla/OneCRL-Tools<br />
|-<br />
| bug-husbandry-bot@mozilla.bugs || ehumphries@moco || rest || api-key || [[Bugmasters/Projects/Bug_Handling/Bug_Husbandry]]<br />
|-<br />
| reviewbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/code-review<br />
|-<br />
| upliftbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/release-services/tree/master/src/uplift/bot<br />
|-<br />
| wptsync@mozilla.bugs || jgraham@mozilla.com || rest || api-key || https://github.com/mozilla/wpt-sync<br />
|-<br />
| release+phabricator@mozilla.com || sfraser@mozilla.com || rest || api-key || Unknown / Phabricator use<br />
|-<br />
| foxsec-pytest@mozilla.com || abahnken@mozilla.com || rest || api-key || https://github.com/mozilla-services/pytest-services<br />
|-<br />
| experimenter@mozilla.com || jbuckley@mozilla.com || rest || api-key || https://github.com/mozilla/experimenter<br />
|-<br />
| bugmail@firebot.glob.uno || glob@mozilla.com || rest || anon || https://github.com/globau/firebot<br />
|-<br />
| bteam-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard<br />
|-<br />
| conduit-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard/tree/conduit<br />
|- <br />
| jitbugs@mozilla.bugs || mgaudet@mozilla.com || n/a || n/a || Watchable Account for JavaScript JIT Bug Reviews<br />
|-<br />
| relops-bug-generator@mozilla.com || jwatkins@mozilla.com || n/a || n/a || Automated Bug Generation for RelOps<br />
|-<br />
| mozilla-apprentice@mcc.id.au || cam@mcc.id.au || rest || api-key || https://github.com/heycam/wg-tracker<br />
|-<br />
| security-baseline@bots.tld || sbennetts@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec<br />
|-<br />
| hlundberg@bots.tld || sstruble@moco || rest || api-key || n/a<br />
|-<br />
| n/a || tom@mozilla.com || rest || api-key || private Google Sheets scripts<br />
|-<br />
| n/a || ktaeleman@mozilla.com || rest || anon || https://github.com/FirefoxGraphics/triage<br />
|-<br />
| n/a || helfi92@gmail.com || rest || api-key || https://github.com/mozilla-frontend-infra/bugzilla-graphql-gateway<br />
|-<br />
| secops-fraud@mozilla.com || abahnken@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec-pipeline/tree/master/contrib/bugzilla-alert-manager<br />
|-<br />
| updatebot@bots.tld || tom@mozilla.com || rest || api-key || https://github.com/mozilla-services/updatebot<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Fingerprinting&diff=1225048Security/Fingerprinting2020-03-13T04:00:12Z<p>Tritter: /* Terse List */</p>
<hr />
<div>== Cross-Origin Fingerprinting Unlinkability ==<br />
The anti-fingerprinting project is part of the Tor Uplift project. <br><br />
Its goal is to build up the same level of fingerprinting resistance as the Tor Browser in Firefox. <br><br />
Refer to the design and implementation document of the Tor Browser: <br><br />
https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability<br />
<br />
== Technical Details ==<br />
<br />
This page contains technical details about the things we do in Resist fingerprinting mode. It is up to date as of March 7, 2018<br />
<br />
<br />
=== Terse List ===<br />
<br />
* Complicated (see below)<br />
** Canvas image extraction is blocked<br />
** Absolute Screen Coordinates are obscured<br />
** Window Dimensions are rounded to a multiple of 200x100, and a warning is shown when maximizing<br />
** We only allow specific system fonts to be used, and we ship them to the user using kinto<br />
<br />
* Non-Trivial (see below)<br />
** The performance API is mostly disabled<br />
** Time Precision is reduced to 100ms, with up to 100ms of jitter<br />
** mozAddonManager may be blocked {{Bug|1384330}}<br />
** Media Devices are spoofed {{Bug|1372073}}<br />
** WebGL is limited {{Bug|1217290}}<br />
** The Keyboard Layout is spoofed <br />
** The Locale is spoofed to en-US<br />
** The Date Input Field and Date Picker Panel are spoofed to en-US {{Bug|1492587}}<br />
** If you customize the preferred language list (Accept-Language), you will be warned {{Bug|1039069}}<br />
** System Media Queries will never match {{Bug|1479240}}<br />
** The Pointer Event is spoofed {{Bug|1363508}} and also pointerEvent.pointerid {{Bug|1492766}}<br />
<br />
* Trivial<br />
** The browser version is reported to be the most recent ESR version (but the OS is not spoofed)<br />
** Timezone is spoofed to 'UTC'<br />
** The gamepad API is disabled<br />
** All device sensors are disabled<br />
** The WebSpeech API is disabled<br />
** WEBGL_debug_renderer_info extension is disabled {{Bug|1337157}}<br />
** navigator.hardwareConcurrency is spoofed to 2<br />
** Site-specific zoom is disabled {{Bug|1369357}}<br />
** MediaError.message is restricted to a whitelist {{Bug|1354633}}<br />
** The Network Information API reports an 'Unknown' connection type, and the ontypechange event is suppressed {{Bug|1372072}}<br />
** The Media Statistics API will report calculated numbers not reflecting reality {{Bug|1369309}}<br />
** Web Extensions are able to toggle privacy.resistFingerprinting<br />
** Geolocation is disabled {{Bug|1372069}} - but this will be reverted {{Bug|1441295}}<br />
** screen.orientation.type is spoofed as 'landscape-primary' and screen.orientation.angle is spoofed to '0' {{Bug|1281949}} but also {{Bug|1433815}}<br />
** navigator.plugins and navigator.mimeTypes are reported as empty {{Bug|1281963}} and {{Bug|1324044}}<br />
** prefers-reduced-motion always returns false {{Bug|1478158}}<br />
** AudioContext OutputLatency is spoofed {{Bug|1564422}}<br />
** prefers-color-scheme always says light mode.<br />
<br />
=== Details ===<br />
<br />
==== Canvas Fingerprinting Detection ====<br />
<br />
==== Absolute Screen Coordinates ====<br />
<br />
{{Bug|1382499}}<br />
<br />
==== Window Dimensions ====<br />
<br />
{{Bug|1330882}}<br />
<br />
==== Fonts ====<br />
<br />
TODO<br />
<br />
==== Performance API ====<br />
<br />
Most performance APIs are disabled, but not all of them. TODO more details.<br />
<br />
==== Time Precision Reduction ====<br />
<br />
TODO more details<br />
<br />
* animation API - {{Bug|1382545}}<br />
<br />
==== mozAddonManager ====<br />
<br />
window.navigator.mozAddonManager is only exposed to addons.mozilla.org. In Resist Fingerprinting mode, we keep it exposed; however if the additional preference 'privacy.resistFingerprinting.block_mozAddonManager' is true, then it is not exposed to AMO<br />
<br />
==== Media Devices ====<br />
<br />
When RFP is enabled, enumerateDevices reports that the user has one camera (named 'Internal Camera') and one microphone (named 'Internal Microphone'). The devicechange event is also suppressed.<br />
<br />
==== WebGL ====<br />
<br />
TODO<br />
<br />
==== Keyboard Layout ====<br />
<br />
{{Bug|1222285}}, {{Bug|1438795}}, {{Bug|1409974}}, {{Bug|1433592}}<br />
<br />
==== Locale ====<br />
<br />
{{Bug|867501}}, {{Bug|1330892}}, {{Bug|1369330}}, {{Bug|1409973}}<br />
<br />
==== Accept-Languages ====<br />
<br />
== Project Schedule ==<br />
* Complete the implementation of MVP in '''Firefox 57 (2017-09-20)'''<br />
** This is being tracked by three milestones M1, M2, and M3<br />
* Feature stabilization and refinement in '''Firefox 58 (2017-11-13)'''<br />
** Perform integration test to identify regressions and Web compatibility issues<br />
** Perform tests to verify the effectiveness of fingerprinting protection<br />
** Fix regressions and any other issues<br />
** Figure out the product strategy of Firefox to roll out this functionality<br />
* Ship the feature in '''Firefox 59 (2018-01-15)<br />
** Tor Browser will be using Firefox ESR 59<br />
<br />
== Bug Tracking ==<br />
All fingerprinting bugs are being tracked under the meta bug: <br><br />
{{Bug|1329996}} - [META] Support anti-fingerprinting protection<br />
<br><br />
<br />
'''Priority Definition'''<br />
* P1: MVP (Minimum Viable Product)<br />
* P2: Nice to Have<br />
* P3: Backlog<br />
* Any bug which is marked as [fp:m1-3] in the Whiteboard is also MVP, regardless of its Priority<br />
<br />
'''Whiteboard Definition'''<br />
* [fingerprinting]: Indicate this is a fingerprinting bug<br />
* [fp:m1]: Target milestone is M1 (2017-06-12 Firefox 55)<br />
* [fp:m2]: Target milestone is M2 (2017-08-02 Firefox 56)<br />
* [fp:m3]: Target milestone is M3 (2017-09-20 Firefox 57)<br />
* [fp-backlog]: Backlog bugs<br />
<br />
== Dashboard ==<br />
=== MVP: M1 Bugs List (2017-06-12 Firefox 55) ===<br />
<bugzilla><br />
{<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"], <br />
"whiteboard":["fp:m1"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</bugzilla><br />
<br />
=== MVP: M2 Bugs List (2017-08-07 Firefox 56) ===<br />
<bugzilla><br />
{<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"], <br />
"whiteboard":["fp:m2"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</bugzilla><br />
<br />
=== MVP: M3 Bugs List (2017-09-25 Firefox 57) ===<br />
<bugzilla><br />
{<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"], <br />
"whiteboard":["fp:m3"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</bugzilla><br />
<br />
=== MVP: Bugs To Be Triaged ===<br />
The following bugs are MVP bugs which are not specified priority yet.<br />
<bugzilla><br />
{<br />
"blocks":"1329996",<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"],<br />
"priority":["--"],<br />
"whiteboard":["fp:m"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</bugzilla><br />
<br />
=== Fingerprinting P2 Bugs List ===<br />
<disabled-bugzilla><br />
{<br />
"blocks":"1329996",<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"], <br />
"priority":["P2"], <br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</disabled-bugzilla><br />
<br />
=== Fingerprinting P3-P5 Bugs List ===<br />
<disabled-bugzilla><br />
{<br />
"blocks":"1329996",<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"], <br />
"priority":["P3", "P4", "P5", "--"], <br />
"include_fields": "id, summary, status, priority, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</disabled-bugzilla><br />
<br />
=== Fingerprinting Breakage ===<br />
<br />
<bugzilla><br />
{<br />
"status":["NEW", "ASSIGNED", "REOPENED", "RESOLVED", "VERIFIED"],<br />
"whiteboard":["fingerprinting-breakage"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</bugzilla><br />
<br />
=== All Open Tagged Fingerprinting Bugs ===<br />
<br />
<disabled-bugzilla><br />
{<br />
"status":["NEW", "ASSIGNED", "REOPENED"],<br />
"whiteboard":["fingerprinting"],<br />
"include_fields": "id, summary, status, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "status, assigned_to"<br />
}<br />
</disabled-bugzilla><br />
<br />
=== Fingerprinting Resolved Bugs ===<br />
<disabled-bugzilla><br />
{<br />
"blocks":"1329996",<br />
"status":["RESOLVED", "VERIFIED"], <br />
"include_fields": "id, summary, priority, product, component, assigned_to, depends_on, whiteboard",<br />
"order": "assigned_to"<br />
}<br />
</disabled-bugzilla></div>Tritterhttps://wiki.mozilla.org/index.php?title=Security_Severity_Ratings&diff=1224464Security Severity Ratings2020-03-02T18:41:00Z<p>Tritter: Point to sub-pages.</p>
<hr />
<div>The Security Severity Ratings page has been split between the [https://wiki.mozilla.org/Security_Severity_Ratings/Web Web Severity Ratings] for Mozilla Websites, Services, and Servers and the [https://wiki.mozilla.org/Security_Severity_Ratings/Client Client Severity Ratings] for Mozilla Applications including Firefox, Fenix, and related.<br />
<br />
* [https://wiki.mozilla.org/Security_Severity_Ratings/Web Web Severity Ratings]<br />
* [https://wiki.mozilla.org/Security_Severity_Ratings/Client Client Severity Ratings]</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1224463User:Tritter/Working/Web Security Severity Ratings2020-03-02T18:36:52Z<p>Tritter: Replaced content with "Published to https://wiki.mozilla.org/Security_Severity_Ratings/Web"</p>
<hr />
<div>Published to https://wiki.mozilla.org/Security_Severity_Ratings/Web</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224462User:Tritter/Working/Client Security Severity Ratings2020-03-02T18:36:45Z<p>Tritter: Replaced content with "Published to https://wiki.mozilla.org/Security_Severity_Ratings/Client"</p>
<hr />
<div>Published to https://wiki.mozilla.org/Security_Severity_Ratings/Client</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security_Severity_Ratings/Web&diff=1224461Security Severity Ratings/Web2020-03-02T18:36:23Z<p>Tritter: Created page with "__TOC__ ==Severity Ratings == In all cases, the severity of server and web application bugs is dependent on the [https://www.mozilla.org/en-US/security/bug-bounty/web-eligib..."</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/ critically of the service] and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guidelines, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to users of our services. Often-times there is no difference technically between a sec-critical and a sec-high, the difference is purely related to to the classification of the site and the risk to users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Remote Code Execution on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical] or [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#core-sites Core] site.<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
* Stored Cross-site Scripting (XSS)<br />
* Reflected XSS on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical Site]<br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Reflected XSS on a non Critical or Core site<br />
* CSRF<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* XSS blocked by CSP<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Whiteboard Tracking Tags & Flags==<br />
<br />
=== wsectype- Keywords ===<br />
<br />
wsectype- keywords are assigned to bugs to indicate the type of a vulnerability. These should be assigned to every vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|wsec-applogic || Issues relating to the application logic<br />
|-<br />
|wsec-appmisconfig || Application misconfiguration<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || Web/server authorization security issues<br />
|-<br />
|wsec-automation-attack || Application is vulnerable to automation attacks<br />
|-<br />
|wsec-bruteforce || Application is vulnerable to bruteforce attacks<br />
|-<br />
|wsec-client || Web client side related vulnerability<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-deplib || Known vulnerability in a dependant library<br />
|-<br />
|wsec-dir-index || Directory index incorrectly accessible<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-email || Email related vulnerability<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-fileinclusion || Local or remote file inclusion possible<br />
|-<br />
|wsec-headers || Missing or misconfigured security headers<br />
|-<br />
|wsec-http || Application is incorrectly accessible over http<br />
|-<br />
|wsec-http-header-inject || Application vulnerable to header injection attacks<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-nullbyte || Application is vulnerable to null byte injection<br />
|-<br />
|wsec-objref || Insecure direct object references used<br />
|-<br />
|wsec-oscmd || Application is vulnerable to Operating System command injection<br />
|-<br />
|wsec-other || Web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-overflow || Application is vulnerable to overflow attacks<br />
|-<br />
|wsec-redirect || Open redirect vulnerability<br />
|-<br />
|wsec-selfxss || Self cross site scripting<br />
|-<br />
|wsec-serialization || Insecure deserialization<br />
|-<br />
|wsec-servermisconfig || Server misconfiguration<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-takeover || Domain vulnerable to takeover<br />
|-<br />
|wsec-tls || TLS related issues<br />
|-<br />
|wsec-traversal || Directory traversal possible<br />
|-<br />
|wsec-weakpasswd || Weak passwords can be used<br />
|-<br />
|wsec-xml || XML related vulnerability including XML External Entity (XXE) processing<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:15%" | Flag <br />
! style="width:25%"| Description<br />
! style="width:60%" | Settings<br />
<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security_Severity_Ratings/Client&diff=1224460Security Severity Ratings/Client2020-03-02T18:36:13Z<p>Tritter: Created page with "__TOC__ The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties,..."</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Sandbox escapes<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
* Most Denial of Service vulnerabilities, such as those requiring a browser restart<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224043User:Tritter/Working/Client Security Severity Ratings2020-02-20T18:41:27Z<p>Tritter: /* Severity Ratings */</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Sandbox escapes<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
* Most Denial of Service vulnerabilities, such as those requiring a browser restart<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224026User:Tritter/Working/Client Security Severity Ratings2020-02-20T15:19:37Z<p>Tritter: /* Severity Ratings */</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
* Most Denial of Service vulnerabilities, such as those requiring a browser restart<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1224025User:Tritter/Working/Web Security Severity Ratings2020-02-20T15:18:35Z<p>Tritter: /* Severity Ratings */</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/ critically of the service] and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guidelines, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to users of our services. Often-times there is no difference technically between a sec-critical and a sec-high, the difference is purely related to to the classification of the site and the risk to users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Remote Code Execution on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical] or [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#core-sites Core] site.<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
* Stored Cross-site Scripting (XSS)<br />
* Reflected XSS on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical Site]<br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Reflected XSS on a non Critical or Core site<br />
* CSRF<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* XSS blocked by CSP<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Whiteboard Tracking Tags & Flags==<br />
<br />
=== wsectype- Keywords ===<br />
<br />
wsectype- keywords are assigned to bugs to indicate the type of a vulnerability. These should be assigned to every vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|wsec-applogic || Issues relating to the application logic<br />
|-<br />
|wsec-appmisconfig || Application misconfiguration<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || Web/server authorization security issues<br />
|-<br />
|wsec-automation-attack || Application is vulnerable to automation attacks<br />
|-<br />
|wsec-bruteforce || Application is vulnerable to bruteforce attacks<br />
|-<br />
|wsec-client || Web client side related vulnerability<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-deplib || Known vulnerability in a dependant library<br />
|-<br />
|wsec-dir-index || Directory index incorrectly accessible<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-email || Email related vulnerability<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-fileinclusion || Local or remote file inclusion possible<br />
|-<br />
|wsec-headers || Missing or misconfigured security headers<br />
|-<br />
|wsec-http || Application is incorrectly accessible over http<br />
|-<br />
|wsec-http-header-inject || Application vulnerable to header injection attacks<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-nullbyte || Application is vulnerable to null byte injection<br />
|-<br />
|wsec-objref || Insecure direct object references used<br />
|-<br />
|wsec-oscmd || Application is vulnerable to Operating System command injection<br />
|-<br />
|wsec-other || Web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-overflow || Application is vulnerable to overflow attacks<br />
|-<br />
|wsec-redirect || Open redirect vulnerability<br />
|-<br />
|wsec-selfxss || Self cross site scripting<br />
|-<br />
|wsec-serialization || Insecure deserialization<br />
|-<br />
|wsec-servermisconfig || Server misconfiguration<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-takeover || Domain vulnerable to takeover<br />
|-<br />
|wsec-tls || TLS related issues<br />
|-<br />
|wsec-traversal || Directory traversal possible<br />
|-<br />
|wsec-weakpasswd || Weak passwords can be used<br />
|-<br />
|wsec-xml || XML related vulnerability including XML External Entity (XXE) processing<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:15%" | Flag <br />
! style="width:25%"| Description<br />
! style="width:60%" | Settings<br />
<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1224024User:Tritter/Working/Web Security Severity Ratings2020-02-20T15:18:13Z<p>Tritter: /* Severity Ratings */</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/|critically of the service] and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guidelines, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to users of our services. Often-times there is no difference technically between a sec-critical and a sec-high, the difference is purely related to to the classification of the site and the risk to users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Remote Code Execution on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical] or [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#core-sites Core] site.<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
* Stored Cross-site Scripting (XSS)<br />
* Reflected XSS on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical Site]<br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Reflected XSS on a non Critical or Core site<br />
* CSRF<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* XSS blocked by CSP<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Whiteboard Tracking Tags & Flags==<br />
<br />
=== wsectype- Keywords ===<br />
<br />
wsectype- keywords are assigned to bugs to indicate the type of a vulnerability. These should be assigned to every vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|wsec-applogic || Issues relating to the application logic<br />
|-<br />
|wsec-appmisconfig || Application misconfiguration<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || Web/server authorization security issues<br />
|-<br />
|wsec-automation-attack || Application is vulnerable to automation attacks<br />
|-<br />
|wsec-bruteforce || Application is vulnerable to bruteforce attacks<br />
|-<br />
|wsec-client || Web client side related vulnerability<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-deplib || Known vulnerability in a dependant library<br />
|-<br />
|wsec-dir-index || Directory index incorrectly accessible<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-email || Email related vulnerability<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-fileinclusion || Local or remote file inclusion possible<br />
|-<br />
|wsec-headers || Missing or misconfigured security headers<br />
|-<br />
|wsec-http || Application is incorrectly accessible over http<br />
|-<br />
|wsec-http-header-inject || Application vulnerable to header injection attacks<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-nullbyte || Application is vulnerable to null byte injection<br />
|-<br />
|wsec-objref || Insecure direct object references used<br />
|-<br />
|wsec-oscmd || Application is vulnerable to Operating System command injection<br />
|-<br />
|wsec-other || Web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-overflow || Application is vulnerable to overflow attacks<br />
|-<br />
|wsec-redirect || Open redirect vulnerability<br />
|-<br />
|wsec-selfxss || Self cross site scripting<br />
|-<br />
|wsec-serialization || Insecure deserialization<br />
|-<br />
|wsec-servermisconfig || Server misconfiguration<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-takeover || Domain vulnerable to takeover<br />
|-<br />
|wsec-tls || TLS related issues<br />
|-<br />
|wsec-traversal || Directory traversal possible<br />
|-<br />
|wsec-weakpasswd || Weak passwords can be used<br />
|-<br />
|wsec-xml || XML related vulnerability including XML External Entity (XXE) processing<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:15%" | Flag <br />
! style="width:25%"| Description<br />
! style="width:60%" | Settings<br />
<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224022User:Tritter/Working/Client Security Severity Ratings2020-02-20T14:56:07Z<p>Tritter: The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224021User:Tritter/Working/Client Security Severity Ratings2020-02-20T14:54:03Z<p>Tritter: add csectype-jit</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-jit || client security issues due to jit miscompilation or similar<br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1224020User:Tritter/Working/Web Security Severity Ratings2020-02-20T14:53:33Z<p>Tritter: /* wsectype- Keywords */</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Remote Code Execution on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical] or [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#core-sites Core] site.<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
* Stored Cross-site Scripting (XSS)<br />
* Reflected XSS on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical Site]<br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Reflected XSS on a non Critical or Core site<br />
* CSRF<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* XSS blocked by CSP<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Whiteboard Tracking Tags & Flags==<br />
<br />
=== wsectype- Keywords ===<br />
<br />
wsectype- keywords are assigned to bugs to indicate the type of a vulnerability. These should be assigned to every vulnerability. If you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|wsec-applogic || Issues relating to the application logic<br />
|-<br />
|wsec-appmisconfig || Application misconfiguration<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || Web/server authorization security issues<br />
|-<br />
|wsec-automation-attack || Application is vulnerable to automation attacks<br />
|-<br />
|wsec-bruteforce || Application is vulnerable to bruteforce attacks<br />
|-<br />
|wsec-client || Web client side related vulnerability<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-deplib || Known vulnerability in a dependant library<br />
|-<br />
|wsec-dir-index || Directory index incorrectly accessible<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-email || Email related vulnerability<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-fileinclusion || Local or remote file inclusion possible<br />
|-<br />
|wsec-headers || Missing or misconfigured security headers<br />
|-<br />
|wsec-http || Application is incorrectly accessible over http<br />
|-<br />
|wsec-http-header-inject || Application vulnerable to header injection attacks<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-nullbyte || Application is vulnerable to null byte injection<br />
|-<br />
|wsec-objref || Insecure direct object references used<br />
|-<br />
|wsec-oscmd || Application is vulnerable to Operating System command injection<br />
|-<br />
|wsec-other || Web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-overflow || Application is vulnerable to overflow attacks<br />
|-<br />
|wsec-redirect || Open redirect vulnerability<br />
|-<br />
|wsec-selfxss || Self cross site scripting<br />
|-<br />
|wsec-serialization || Insecure deserialization<br />
|-<br />
|wsec-servermisconfig || Server misconfiguration<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-takeover || Domain vulnerable to takeover<br />
|-<br />
|wsec-tls || TLS related issues<br />
|-<br />
|wsec-traversal || Directory traversal possible<br />
|-<br />
|wsec-weakpasswd || Weak passwords can be used<br />
|-<br />
|wsec-xml || XML related vulnerability including XML External Entity (XXE) processing<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:15%" | Flag <br />
! style="width:25%"| Description<br />
! style="width:60%" | Settings<br />
<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1224019User:Tritter/Working/Web Security Severity Ratings2020-02-20T14:52:58Z<p>Tritter: delete sec-review</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Remote Code Execution on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical] or [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#core-sites Core] site.<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
* Stored Cross-site Scripting (XSS)<br />
* Reflected XSS on a [https://www.mozilla.org/en-US/security/bug-bounty/web-eligible-sites/#critical-sites Critical Site]<br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Reflected XSS on a non Critical or Core site<br />
* CSRF<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* XSS blocked by CSP<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Whiteboard Tracking Tags & Flags==<br />
<br />
=== wsectype- Keywords ===<br />
<br />
wsectype- keywords are assigned to bugs to indicate the type of a vulnerability. These should be assigned to every vulnerability.<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:30%" | Code <br />
! style="width:70%"| Description<br />
|-<br />
|wsec-applogic || Issues relating to the application logic<br />
|-<br />
|wsec-appmisconfig || Application misconfiguration<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || Web/server authorization security issues<br />
|-<br />
|wsec-automation-attack || Application is vulnerable to automation attacks<br />
|-<br />
|wsec-bruteforce || Application is vulnerable to bruteforce attacks<br />
|-<br />
|wsec-client || Web client side related vulnerability<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-deplib || Known vulnerability in a dependant library<br />
|-<br />
|wsec-dir-index || Directory index incorrectly accessible<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-email || Email related vulnerability<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-fileinclusion || Local or remote file inclusion possible<br />
|-<br />
|wsec-headers || Missing or misconfigured security headers<br />
|-<br />
|wsec-http || Application is incorrectly accessible over http<br />
|-<br />
|wsec-http-header-inject || Application vulnerable to header injection attacks<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-nullbyte || Application is vulnerable to null byte injection<br />
|-<br />
|wsec-objref || Insecure direct object references used<br />
|-<br />
|wsec-oscmd || Application is vulnerable to Operating System command injection<br />
|-<br />
|wsec-other || Web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-overflow || Application is vulnerable to overflow attacks<br />
|-<br />
|wsec-redirect || Open redirect vulnerability<br />
|-<br />
|wsec-selfxss || Self cross site scripting<br />
|-<br />
|wsec-serialization || Insecure deserialization<br />
|-<br />
|wsec-servermisconfig || Server misconfiguration<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-takeover || Domain vulnerable to takeover<br />
|-<br />
|wsec-tls || TLS related issues<br />
|-<br />
|wsec-traversal || Directory traversal possible<br />
|-<br />
|wsec-weakpasswd || Weak passwords can be used<br />
|-<br />
|wsec-xml || XML related vulnerability including XML External Entity (XXE) processing<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 80%;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:15%" | Flag <br />
! style="width:25%"| Description<br />
! style="width:60%" | Settings<br />
<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:10%" | Setting <br />
! style="width:90%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1224018User:Tritter/Working/Client Security Severity Ratings2020-02-20T14:52:30Z<p>Tritter: Delete sec-review</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=BMO/Bot_Registry&diff=1223993BMO/Bot Registry2020-02-19T21:50:51Z<p>Tritter: </p>
<hr />
<div>Some times you want a BMO account that is not a real person.<br />
That's okay -- in fact it is a good security measure!<br />
<br />
However this comes with some problems -- if we (the bmo admins) can't tell who owns a bot,<br />
and we have to make a decision that might break we have no way of informing the owner except<br />
to break it and wait to hear back. This list below is by no means mandatory, but if you fill it out,<br />
we can help avoid future breakages!<br />
<br />
If you include a link to the repo, things can be even smoother.<br />
<br />
If your bot misbehaves, we can tell you about it rather than just blocking it. <br />
<br />
== Bot Requirements ==<br />
<br />
All bot and automation users:<br />
<br />
* '''must''' have a `bots.tld` bugmail by 2020-06-30<br />
* '''must''' use the REST api by 2020-06-30<br />
* if they have elevated privileges must use a API key by 2020-06-30<br />
* '''should''' be listed in this registry ''unless'' there is a business reason not to list them publicly<br />
* when they modify bugs, they '''should''' leave a comment that the bug has been modified by a bot unless it does not make sense to<br />
<br />
== Bot List ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Bot Bugmail !! Owner Bugmail !! API (xmlrpc, jsonrpc, bzapi, or rest) !! Token or API Key!! Repo<br />
|-<br />
| pulsebot@bots.tld || mh+mozilla@glandium.org || rest || api-key || https://github.com/glandium/pulsebot/<br />
|-<br />
| treeherderbugbot@gmail.com || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || xmlrpc || Username/password || [https://github.com/github/github-services/blob/master/lib/services/bugzilla.rb GitHub's Bugzilla integration]<br />
|-<br />
| intermittent-bug-filer@mozilla.bugs || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || rest || api-key || https://github.com/mozilla/treeherder<br />
|-<br />
| orangefactor@bots.tld || auto-tools@moco || rest || api-key || https://hg.mozilla.org/automation/orangefactor/<br />
|-<br />
| webops-kanban@mozilla.bugs || atoll || Unknown || Token || <br />
|-<br />
| mozilla+bugcloser@davedash.com || Unknown || Unknown || Token (github) || Unknown<br />
|-<br />
| release-mgmt-account-bot@mozilla.tld || cdenizet@mozilla.com || rest || api-key || https://github.com/mozilla/relman-auto-nag/<br />
|-<br />
| slaveapi@mozilla.releng.tld || release@mozilla.com || Unknown || Unknown || https://github.com/mozilla/build-slaveapi<br />
|-<br />
| flow2bugs@netops.bugs || unknown || Unknown || Unknown || Unknown<br />
|- <br />
| webcompat-bugs@mozilla.bugs || miket@mozilla.com || rest || api-key || TBD<br />
|-<br />
| pulgasaur@mozilla.bugs || peterbe@mozilla.com || rest || api-key || https://github.com/mozilla/github-bugzilla-pr-linker<br />
|-<br />
| moc-queue-bot@mozilla.bugs || moc@mozilla.com || rest || api-key || git-internal/puppet/modules/moc_bug_queuemon<br />
|-<br />
| omphalos@mozilla.bugs || mgoodwin@mozilla.com || rest || api-key || https://github.com/mozilla/OneCRL-Tools<br />
|-<br />
| bug-husbandry-bot@mozilla.bugs || ehumphries@moco || rest || api-key || [[Bugmasters/Projects/Bug_Handling/Bug_Husbandry]]<br />
|-<br />
| reviewbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/code-review<br />
|-<br />
| upliftbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/release-services/tree/master/src/uplift/bot<br />
|-<br />
| wptsync@mozilla.bugs || jgraham@mozilla.com || rest || api-key || https://github.com/mozilla/wpt-sync<br />
|-<br />
| release+phabricator@mozilla.com || sfraser@mozilla.com || rest || api-key || Unknown / Phabricator use<br />
|-<br />
| foxsec-pytest@mozilla.com || abahnken@mozilla.com || rest; xmlrpc || api-key || https://github.com/mozilla-services/pytest-services<br />
|-<br />
| experimenter@mozilla.com || jbuckley@mozilla.com || rest || api-key || https://github.com/mozilla/experimenter<br />
|-<br />
| bugmail@firebot.glob.uno || glob@mozilla.com || rest || anon || https://github.com/globau/firebot<br />
|-<br />
| bteam-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard<br />
|-<br />
| conduit-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard/tree/conduit<br />
|- <br />
| jitbugs@mozilla.bugs || mgaudet@mozilla.com || n/a || n/a || Watchable Account for JavaScript JIT Bug Reviews<br />
|-<br />
| relops-bug-generator@mozilla.com || jwatkins@mozilla.com || n/a || n/a || Automated Bug Generation for RelOps<br />
|-<br />
| mozilla-apprentice@mcc.id.au || cam@mcc.id.au || rest || api-key || https://github.com/heycam/wg-tracker<br />
|-<br />
| security-baseline@bots.tld || sbennetts@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec<br />
|-<br />
| hlundberg@bots.tld || sstruble@moco || rest || api-key || n/a<br />
|-<br />
| n/a || tom@mozilla.com || rest || api-key || private Google Sheets scripts<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1223555User:Tritter/Working/Client Security Severity Ratings2020-02-11T18:59:35Z<p>Tritter: /* Alternate Keywords */</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Building_Firefox/SURF&diff=1223527Building Firefox/SURF2020-02-11T15:39:40Z<p>Tritter: /* How do I add logging to my code to figure out what is going on? */</p>
<hr />
<div>This page is to serve as a guide for interested researchers (primarily academic researchers) who would like to experiment with Firefox for research purposes. Such experiments might include:<br />
<br />
* Developing new compiler features, performance improvements, or security mechanisms<br />
* Altering the behavior of the browser with respect to the web platform<br />
* Creating a web scanning platform based on the browser (similar to [https://github.com/mozilla/OpenWPM OpenWPM])<br />
<br />
Or something entirely different. Be creative.<br />
<br />
== Building Firefox Locally ==<br />
<br />
The first step will almost certainly be to build the browser locally. Firefox has a well maintained mechanism for obtaining the dependencies needed to build it, even on Windows. Follow the [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build Developer guide at MDN] to build Firefox for the first time locally.<br />
<br />
Once you've built it, use <tt>./mach run</tt> to start the browser and take it for a spin.<br />
<br />
== Running Tests (Locally) ==<br />
<br />
<tt>./mach test path/to/test</tt> will run most types of tests; for example <tt>./mach test [https://searchfox.org/mozilla-central/source/dom/security/test/csp/test_upgrade_insecure.html dom/security/test/csp/test_upgrade_insecure.html]</tt> <br />
<br />
You can add --headless (after 'test') to run them without launching the browser window. This is useful when working on a remote server. Note however that while --headless works most of the time, if a test fails to run, it is worth re-running it without --headless in a GUI environment.<br />
<br />
gtests are run differently, for example <tt>./mach gtest "*ReducePrecision_*"</tt> to run tests with 'ReducePrecision_' in their name (which would be [https://searchfox.org/mozilla-central/rev/05a22d864814cb1e4352faa4004e1f975c7d2eb9/toolkit/components/resistfingerprinting/tests/test_reduceprecision.cpp#82 tests like these]).<br />
<br />
While you can use <tt>./mach test mochitest</tt> to run all mochitests; or <tt>./mach test</tt> to run <i>all</i> tests - doing this locally is going to produce false positives and generally be unpleasant. Instead the next step is to move to <tt>try</tt>.<br />
<br />
== Building and Testing in Mozilla Infrastructure ==<br />
<br />
<i>Note that all try runs are public, and presently Mozilla does not have a mechanism to do private builds or test runs.</i><br />
<br />
The <tt>TryServer</tt> is a way to submit a one or more patches and have them built on multiple Operating Systems, run tests, and download builds and logs. Because the entire build system is specified <i>in the mozilla-central tree as configuration files</i> it is possible to write a patch that changes the compiler used (either to a different version, or actually patching the compiler), have the tryserver check out the compiler source from a remote repository, build the compiler, and then use the compiler to build Firefox. All in the cloud. https://wiki.mozilla.org/ReleaseEngineering/TryServer has more information about the TryServer, but we will aim to have a functional quickstart tutorial in this document.<br />
<br />
=== Getting Access ===<br />
<br />
Before submitting to try, you will need to contact SURF at the email [mailto:surf@mozilla.com surf@mozilla.com] and provide us with some information about who you are and roughly what type of research you are doing. We will treat this as privileged information and not share it outside the SURF initiative, except with other Mozilla engineers to help you debug or diagnose issues. <i>(Note above; however, that try runs including the patches, builds, and logs are public.)</i><br />
<br />
Once we've had a conversation, we will help you through the process of getting Level 1 commit access, which will give you access to try. This process is documented at https://www.mozilla.org/en-US/about/governance/policies/commit/<br />
<br />
The TryServer represents a significant cost for Mozilla - especially for special Operating Systems. We expect that you will be judicious about your use of try. In particular:<br />
<br />
* Build jobs for Windows (except the mingw-clang builds) and all Windows tests occur on Windows hardware and are more expensive. <br />
* While OSX build jobs run on Linux; tests for OSX run on OSX and are expensive and in-demand<br />
* Android builds also run on Linux; but tests run on Android hardware and emulators and are also in-demand and expensive<br />
* Talos tests (which are performance tests) are expensive because they run on native hardware (Android, Windows, and OSX especially so) and need to be retriggered multiple times.<br />
<br />
A good rule of thumb is to get thing working with linux64 debug builds (running the full unit test suite is generally fine) and after that works; move on to building and running debug+optimized builds and unit tests on OSX and Windows. Until you are ready to measure performance, we ask you omit Talos jobs. Unless your research is specifically related to Android (and we would request you tell us that ahead of time) - we ask you not to run Android jobs.<br />
<br />
=== Your First Try Run ===<br />
<br />
Let's get the preliminaries out of the way:<br />
<br />
# Ensure that ssh is properly configured with the ssh key you created during your commit access process (e.g. using ssh-agent + ssh-add, or editing .ssh/config)<br />
# Create a test commit<br />
# Ensure your working directory is clear (that you have have no modified files with <tt>hg status</tt>).<br />
<br />
After that there are multiple ways to push to try; but the two most common are:<br />
<br />
==== Fuzzy ====<br />
<br />
Fuzzy is the currently supported and encouraged method for pushing to try.<br />
<br />
<pre>./mach try fuzzy</pre><br />
<br />
Fuzzy allows you to very selectively choose what tasks to run. [https://firefox-source-docs.mozilla.org/tools/try/selectors/fuzzy.html Its documentation is located here.] It will automatically figure out dependencies; so if you choose to only run linux64-mochitests, it will schedule the needed linux64 build job as well. <br />
<br />
Once you have pushed using <tt>./mach try fuzzy</tt> once; <tt>./mach try again</tt> will submit the configuration of the last push. Fuzzy has lots more [https://firefox-source-docs.mozilla.org/tools/try/selectors/again.html additional options].<br />
<br />
==== Legacy Try Syntax ====<br />
<br />
This try syntax is deprecated; but still commonly used for its terse-ness.<br />
<br />
<pre>./mach try -b do -p linux64 -u all -t none</pre><br />
<br />
* -b means 'build type' and valid values are 'd', 'o', or 'do' and they stand for 'debug' and 'optimized'.<br />
* -p means 'platform'. The most commonly used values are 'linux' (meaning x86), 'linux64', 'win32', 'win64', and 'macosx64'. They are separated by commas, no spaces.<br />
* -u means 'unit tests'. If you are using this syntax you would typically choose either 'all' or 'none'<br />
* -t means 'talos tests' (which are our performance tests.) Choose 'none'<br />
<br />
There are a couple of other flags that are commonly used:<br />
<br />
<pre>./mach try -b do -p linux64,win64 -u none -t all --rebuild-talos=5<br />
./mach try -b do -p linux64 -u all -t none --setenv="MOZ_LOG=CSMLog:3"<br />
./mach try -b do -p linux64 dom testing/web-platform/tests/dom</pre><br />
<br />
* --rebuild-talos=5 indicates that Talos jobs should be run 5 times (so you can average the performance.) Talos jobs only run on opt and pgo builds.<br />
* --setenv="MOZ_LOG=CSMLog:3" is how to pass environment variables to the test runs. Typically this is used to get logging. (More on this later)<br />
* 'dom testing/web-platform/tests/dom' (positional arguments) are a way to specify that only tests in these directories should be run.<br />
<br />
=== Viewing your try run ===<br />
<br />
After you submit your try run, it will give you a link that looks like https://treeherder.mozilla.org/#/jobs?repo=try&revision=2827e91340e5b62da31628d8f27546e3a7d53d82 (this link may not work after this job ages out of try; but https://treeherder.mozilla.org will show a view of lots of recent jobs.<br />
<br />
Here's a quick overview of the most commonly used features.<br />
<br />
[[File:Treeherder-job-view.png|frameless|center]]<br />
<br />
Here's what the red numbers mean:<br />
<br />
# Here is the list of commits in your push to try. '''Note''': Only *new* commits never seen by the try repository are listed here. So if you send a job to try with Commit A, and then a subsequent job with a new Commit B - you will only see Commit B listed. If you `hg histedit` and edit A, then submit again - you will see commit A' (the edited commit A) and commit B' (B wasn't edited, but it has a new parent so it becomes B'.)<br />
# This is the job view. If you send a lot of builds and tests up, this can get pretty crowded. Mouse over things to get a tooltip for what they are. +6 means a group containing 6 sub-items. Build jobs begin with '''B''', and typically the 'normal' Build for this platform will just be a plain B. Here we've selected the Linux x64 Debug Build Job. It's caused a pane at the bottom to open.<br />
# There are two ways to view logs from a job. The Log icon that is below and slightly to the left of the (3) icon - this log view is a web-based reader that is fast to load. The icon directly below the (3) takes you to the full, raw log. I prefer this log personally, even if it takes 45 seconds to load.<br />
# The ... menu directly below the (4) contains an option to "Create an Interactive Task". This lets you connect to the build job and, if it fails, take a look at the error and poke around the system to see what might have gone wrong. Very handy.<br />
# If you select the Job Details tab on a Build ob, you'll see a list of files here like (5). Here you can download your build. It will be in a archive named 'target'. Other built objects - like tests - will be target.foo archives.<br />
<br />
==== Adding stuff to a Try Run, or re-running jobs ====<br />
<br />
If you have an existing try run that you want to add jobs to (for example additional build jobs, or to re-run tests) this can be done from the treeherder web interface without needing to send in a new try job. The option to do this is behind the downward-facing arrow, at the top of the treeherder UI on the left-hand side, next to 'View Tests' and the pin icon.<br />
<br />
For example, if you want to see if a test always fails, or only some of the time, you can re-trigger the test on an existing job, rather than submit a whole new try push that will perform a build step also. To retrigger a job, select it in the UI (so its details show up in the bottom pane) and press the 'r' key. It's a shortcut. Pressing the '?' key will show you the shortcut list.<br />
<br />
For another example, if your build and tests worked successfully for one platform; and you want to test a second one - you can add the tests on the web interface. This has the advantage of keeping all your results for a single patchset in one place. See [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder Scheduling jobs with Treeherder] and [https://wiki.mozilla.org/ReleaseEngineering/TryServer#Scheduling_jobs_with_Treeherder_.28Search.29 Scheduling jobs with Treeherder (Search)].<br />
<br />
The only caveat to this method is that it can be easy to add tests that are not typically run in a normal try run and may currently be failing in general - independent of your patchset. So keep that in mind if you get unexpected failures.<br />
<br />
== Frequently Asked Questions ==<br />
<br />
=== How do I modify the compiler used to build Firefox? ===<br />
<br />
There's two answers to this question. <br />
<br />
'''Locally''': Inside your mozconfig, you can set the following like <tt>export FOO="bar"</tt><br />
<br />
* CC - C compiler used to compile firefox<br />
* CFLAGS<br />
* CPPFLAGS<br />
* HOST_CC - used to compile utilities that will run on the build machine<br />
* HOST_CFLAGS<br />
* CXX / HOST_CXX - C++ compiler<br />
* CXXFLAGS / HOST_CXXFLAGS<br />
* LLVM_CONFIG<br />
* RUSTC / CARGO / RUSTDOC / RUSTFMT / CBINDGEN<br />
<br />
Less commonly you may need to set<br />
<br />
* AR / AS / RANLIB / STRIP / OTOOL / OBJCOPY / LIPO / NASM / NODEJS / MAKECAB<br />
* BINDGEN_CFLAGS - for rust bindgen<br />
<br />
You may also need to set:<br />
<br />
* <tt>ac_add_options --with-toolchain-prefix=foo</tt> - used for a cross compile. [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/browser/config/mozconfigs/win32/mingwclang#32 example]<br />
* <tt>mk_add_options "export PATH=directory:$PATH"</tt> - to add more PATHs<br />
* <tt>LD_LIBRARY_PATH</tt> - [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/browser/config/mozconfigs/win32/mingwclang#62-63 as shown here]<br />
<br />
<br />
'''In Try''': In try, you'll need to build your compiler and then use it. I'm going to assume you're building clang and working on linux64.<br />
<br />
Here's a quick tour of where things are first though. The linux64 builds are defined in [https://searchfox.org/mozilla-central/source/taskcluster/ci/build/linux.yml this file]. Look for 'linux64/debug'. Some important things to note are ''mozconfig-variant'' and ''fetches''. You match the mozconfig-variant with the corresponding file in [https://searchfox.org/mozilla-central/source/browser/config/mozconfigs/linux64 this directory]. Observe that the debug mozconfig pulls in additional mozconfigs. But modifying this mozconfig will modify the linux64 debug build.<br />
<br />
fetches->toolchain will match up with the keywords defined in the [https://searchfox.org/mozilla-central/source/taskcluster/ci/toolchain toolchain definitions]. So if we're looking for 'linux64-clang' we can [https://searchfox.org/mozilla-central/search?q=linux64-clang&case=false&regexp=false&path=taskcluster%2Fci%2Ftoolchain search for it] and see that while there is nothing defining 'linux64-clang' and a key (it would end in a : (colon)) - there is something saying <tt>toolchain-alias: linux64-clang</tt>. If we follow that, we can see at time of writing, it is defined as [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/taskcluster/ci/toolchain/clang.yml#60 linux64-clang-9]. (This link is a permalink to an old file, it may be different when you read this.)<br />
<br />
Let's figure out how we build this toolchain. We want to look at ''build-clang.sh'', which receives the argument ''build/build-clang/clang-linux64.json''. It fetches the clang source using a keyword defined as ''clang-9'' (under fetches->fetch) and this compiler is itself built using the toolchains ''linux64-binutils'' and ''linux64-gcc-7''. (We could follow binutils and gcc-7 to find where they come from also, but we won't do that in this tutorial.)<br />
<br />
First let's match ''clang-9'' to the source code. We do that by searching for clang-9 in the [https://searchfox.org/mozilla-central/source/taskcluster/ci/fetch/toolchains.yml toolchain's fetch file]. We see the repository it comes from and the git revision we check out.<br />
<br />
Then we can find [https://searchfox.org/mozilla-central/source/taskcluster/scripts/misc/build-clang.sh build-clang.sh] - it looks like most of the heavy lifting is done by a script called [https://searchfox.org/mozilla-central/source/build/build-clang/build-clang.py build-clang.py]. We can also find [https://searchfox.org/mozilla-central/source/build/build-clang/clang-linux64.json clang-linux64.json]. Of special note, is that the json file specifies where to find the compiler to compile clang, as well as patches to apply to clang before compiling it. (It might be simpler for you to point the source code fetch to your own repo, rather than adding patches in the json file though.)<br />
<br />
So - using permanent links to a mozilla-central repo as of 11/4/2019 - the steps to build a compiler to compile Firefox with are<br />
<br />
# [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/taskcluster/ci/fetch/toolchains.yml#411-416 Download the clang source code as specified here]<br />
# [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/taskcluster/ci/toolchain/clang.yml#49-67 Build the source code using the job specified here]<br />
## This calls [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/taskcluster/scripts/misc/build-clang.sh build-clang.sh] with [https://searchfox.org/mozilla-central/source/build/build-clang/clang-linux64.json clang-linux64.json] which passes that argument to [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/build/build-clang/build-clang.py build-clang.py]<br />
## We patch the clang source code using the patches specified in the json file before building it.<br />
# We build the linux64 debug job [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/taskcluster/ci/build/linux.yml#113-147 using the job specified here] (which defines what toolchains to use) and the we use [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/browser/config/mozconfigs/linux64/debug the mozconfig specified here].<br />
## If we follow the mozconfig include tree, we find that [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/build/unix/mozconfig.unix mozconfig.unix] is where we set the CC and CXX variables. <br />
<br />
Modifying components of those steps is how you'd customize the compiler used to build Firefox.<br />
<br />
You may also need to set<br />
<br />
<tt>ac_add_options --disable-warnings-as-errors</tt> - if your compiler produces new warnings, we may treat them as errors and abort. This will stop that.<br />
<br />
=== How do I add logging to my code to figure out what is going on? ===<br />
<br />
With MOZ_LOG. [https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/nsRFPService.cpp nsRFPService.cpp] has many examples of it being used. Here's some notes:<br />
<br />
# You'll need to declare something like <tt>static mozilla::LazyLogModule gResistFingerprintingLog("nsResistFingerprinting");</tt><br />
# The format is odd. It's MOZ_LOG(module, severity (format string, args)). Note that second set of parens.<br />
# The list of severities are [https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/xpcom/base/Logging.h#55 defined here]<br />
# To see the logfile output, run Firefox with the environment variable MOZ_LOG="moduleName:5,secondModule:3"<br />
# You can send the logs to files by setting MOZ_LOG_FILE="path-to-file.txt"<br />
# On Windows, due to weirdness, to see the log output from sub-processes you need to either redirect them to a file (or tee) in the console or specify MOZ_LOG_FILE<br />
# [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging This page] has more details. As always, be wary that things may be out of date.</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1223050User:Tritter/Working/Web Security Severity Ratings2020-02-03T17:40:54Z<p>Tritter: /* Alternate Keywords */</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Really bad stuff.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* XSS (Stored)<br />
* CSRF<br />
* Remoce Code Execution<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Cross-site Scripting (XSS)<br />
* XSS (Reflected)<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used. <b>sec-want, sec-audit,</b> and <b>sec-vector</b> are not used for Web client bugs.<br />
<br />
=== wsectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || web/server authorization security issues<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-other || web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== opsectype- Keywords ===<br />
<br />
opsectype- keywords are assigned to bugs relating to Operations Security (Mozilla owned & operated severs and services)<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
| opsec-access<br />
| The identified issue is an access violation.<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Whiteboard Tags<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<strike><b>sec-assigned:UserAlias</b></strike> <b>depricated for sec-review? flag with alias</b><br />
|This designates the assigned security resource that is accountable for actions to be taken on the designated item. When possible the bug will be assigned to the security contact for action. This will be used when that is not possible or practical.<br />
|sec-review?:curtisk@blah.bah indicates that curtisk is the accountable party for action<br />
|-<br />
|<b>[Q2]</b><br />
|This designates a bug as being identified as a request to be done or targeted for a given operational quarter. If no year is given it is for the current year.<br />
|[Q2] indicates second quarter of the current calendar year, [Q1-2013] would be used to indicate a target for an upcoming quarter that has not occurred. <br />
|-<br />
|<b>[k90]</b><br />
|This designates a bug as being part of the Kilimanjaro effort so that it can be tracked, triaged and given appropriate priority and attention.<br />
|<br />
|-<br />
|<b>[basecamp]</b><br />
|This designates a bug as being part of the basecamp sub effort of the Kilimanjaro effort.<br />
|<br />
|- <br />
|<b>[fennec]</b><br />
|This designates a bug as being a critical bug for the efforts around our mobile browser project. This could be combined with either the [k9o] or [basecamp] tags as a bug could be part of both.<br />
|<br />
|-<br />
|<b>[triage needed]</b><br />
|Used to mark a bug for weekly triage meeting.<br />
|<br />
|-<br />
|<strike><b>[pending secreview]</b></strike> deprecated<br />
| Indicates a secreview or tasks related to said review are yet to be completed.<br />
|<br />
|-<br />
|<b>[start mm/dd/yyyy][target mm/dd/yyyy]</b><br />
|This indicates that expected dates to start and complete work on a given review or security bug.<br />
|[start 01/29/2013][target 02/09/2013] indicates work will start on 29-Jan and expected target for completion on 09-Feb<br />
|-<br />
|<strike><b>[completed secreview]</b></strike> deprecated<br />
| Indicates the given secreview or related tasks have been completed<br />
|<br />
|-<br />
|<b>mentorship</b><br />
| Indicates that a given bug is part of our security mentorship program. The assignee of said bug is the Mozilla mentor for such a bug.<br />
|<br />
|-<br />
|<strike><b>[score:##]</b></strike> deprecated<br />
|This indicates the relative severity score for risk rating bugs per the calculator at https://people.mozilla.com/~ckoenig/<br />
|[score:30:moderate] shows that the issue has a numerical score of 30 and a severity of moderate.<br />
|-<br />
|<b>[Web]</b><br />
|Indicates an item related to our Web properties<br />
|<br />
|-<br />
|<b>u= c= p=</b><br />
|These items are used to allow bugs to be tracked by scrumbu.gs for work tracking ([http://scrumbu.gs/help/ more info]).<br />
|<br />
|-<br />
|<b>s=</b><br />
|This tag is used in conjunction with the scrumbu.gs tags above to indicate which sprint a given bug has been assigned.<br />
|s=13q4.1 indicates the bug is in the year 2013, 4th quarter and sprint 1. Each sprint is 2 weeks long and it's calendar dates can be tracked on scrumbu.gs<br />
|-<br />
|}<br />
<br />
=== Feature Page Codes ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Feature Page Codes<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<b>sec-review-needed</b><br />
|A security review is needed for the feature, this could mean a variety of things. If there is no <username> in the notes then a full review needs to be scheduled, if a <username> is present than that person will follow-up with the feature team on whatever task is needed.<br />
|<br />
|-<br />
|<b>sec-review-complete</b><br />
|The security review / actions desired have been completed. This will result in a link to the notes from security actions or a note from the assigned resource.<br />
|<br />
|-<br />
|<b>sec-review-active</b><br />
| There are active tasks associated with the review that are yet to be completed in order for the review to be seen as completed. These will be captured in the "Action Items" section of the review notes.<br />
|<br />
|-<br />
|<b>sec-review-sched</b><br />
| Security review tasks have been scheduled, if this is a full security review the date of the scheduled review will be present in the security notes.<br />
|<br />
|-<br />
|<b>sec-review-unnecessary</b><br />
| After triage it was felt the feature needed no review or security actions. <br />
|<br />
|-<br />
| <b>Security health: <blank></b><br />
| There are no notes or status is unknown.<br />
| Color: <None><br />
|-<br />
| <b>Security health: OK</b><br />
| The tasks are on schedule or completed and are considered non-blocking.<br />
| {{StatusHealthy|status=Color: Green}}<br />
|-<br />
| <b>Security health: Blocked</b><br />
| Some aspect of the security review has given cause to block the feature from further work or landing. The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusBlocked|status=Color: Yellow}}<br />
|-<br />
| <b>Security health: At Risk</b><br />
| Some aspect of the security review may cause the feature to be blocked or put the feature at risk of being off schedule.The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusAtRisk|status=Color: Red}}<br />
|-<br />
| <b>Security health: Assigned</b><br />
| Security tasks have been assigned to a member of the team to followup. The name of this resource will be in the security notes.<br />
| {{StatusAssigned|status=Color: Teal}}<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1223049User:Tritter/Working/Client Security Severity Ratings2020-02-03T17:40:13Z<p>Tritter: /* Alternate Keywords */</p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
* Bugs relating to Firefox for iOS where the vulnerability is actually in Apple's WebKit<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
A historical keyword is <b>sec-incident</b>, which is no longer used.<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1223048User:Tritter/Working/Web Security Severity Ratings2020-02-03T17:38:50Z<p>Tritter: </p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Really bad stuff.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* XSS (Stored)<br />
* CSRF<br />
* Remoce Code Execution<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Cross-site Scripting (XSS)<br />
* XSS (Reflected)<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
|}<br />
<br />
=== wsectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || web/server authorization security issues<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-other || web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== opsectype- Keywords ===<br />
<br />
opsectype- keywords are assigned to bugs relating to Operations Security (Mozilla owned & operated severs and services)<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
| opsec-access<br />
| The identified issue is an access violation.<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Whiteboard Tags<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<strike><b>sec-assigned:UserAlias</b></strike> <b>depricated for sec-review? flag with alias</b><br />
|This designates the assigned security resource that is accountable for actions to be taken on the designated item. When possible the bug will be assigned to the security contact for action. This will be used when that is not possible or practical.<br />
|sec-review?:curtisk@blah.bah indicates that curtisk is the accountable party for action<br />
|-<br />
|<b>[Q2]</b><br />
|This designates a bug as being identified as a request to be done or targeted for a given operational quarter. If no year is given it is for the current year.<br />
|[Q2] indicates second quarter of the current calendar year, [Q1-2013] would be used to indicate a target for an upcoming quarter that has not occurred. <br />
|-<br />
|<b>[k90]</b><br />
|This designates a bug as being part of the Kilimanjaro effort so that it can be tracked, triaged and given appropriate priority and attention.<br />
|<br />
|-<br />
|<b>[basecamp]</b><br />
|This designates a bug as being part of the basecamp sub effort of the Kilimanjaro effort.<br />
|<br />
|- <br />
|<b>[fennec]</b><br />
|This designates a bug as being a critical bug for the efforts around our mobile browser project. This could be combined with either the [k9o] or [basecamp] tags as a bug could be part of both.<br />
|<br />
|-<br />
|<b>[triage needed]</b><br />
|Used to mark a bug for weekly triage meeting.<br />
|<br />
|-<br />
|<strike><b>[pending secreview]</b></strike> deprecated<br />
| Indicates a secreview or tasks related to said review are yet to be completed.<br />
|<br />
|-<br />
|<b>[start mm/dd/yyyy][target mm/dd/yyyy]</b><br />
|This indicates that expected dates to start and complete work on a given review or security bug.<br />
|[start 01/29/2013][target 02/09/2013] indicates work will start on 29-Jan and expected target for completion on 09-Feb<br />
|-<br />
|<strike><b>[completed secreview]</b></strike> deprecated<br />
| Indicates the given secreview or related tasks have been completed<br />
|<br />
|-<br />
|<b>mentorship</b><br />
| Indicates that a given bug is part of our security mentorship program. The assignee of said bug is the Mozilla mentor for such a bug.<br />
|<br />
|-<br />
|<strike><b>[score:##]</b></strike> deprecated<br />
|This indicates the relative severity score for risk rating bugs per the calculator at https://people.mozilla.com/~ckoenig/<br />
|[score:30:moderate] shows that the issue has a numerical score of 30 and a severity of moderate.<br />
|-<br />
|<b>[Web]</b><br />
|Indicates an item related to our Web properties<br />
|<br />
|-<br />
|<b>u= c= p=</b><br />
|These items are used to allow bugs to be tracked by scrumbu.gs for work tracking ([http://scrumbu.gs/help/ more info]).<br />
|<br />
|-<br />
|<b>s=</b><br />
|This tag is used in conjunction with the scrumbu.gs tags above to indicate which sprint a given bug has been assigned.<br />
|s=13q4.1 indicates the bug is in the year 2013, 4th quarter and sprint 1. Each sprint is 2 weeks long and it's calendar dates can be tracked on scrumbu.gs<br />
|-<br />
|}<br />
<br />
=== Feature Page Codes ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Feature Page Codes<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<b>sec-review-needed</b><br />
|A security review is needed for the feature, this could mean a variety of things. If there is no <username> in the notes then a full review needs to be scheduled, if a <username> is present than that person will follow-up with the feature team on whatever task is needed.<br />
|<br />
|-<br />
|<b>sec-review-complete</b><br />
|The security review / actions desired have been completed. This will result in a link to the notes from security actions or a note from the assigned resource.<br />
|<br />
|-<br />
|<b>sec-review-active</b><br />
| There are active tasks associated with the review that are yet to be completed in order for the review to be seen as completed. These will be captured in the "Action Items" section of the review notes.<br />
|<br />
|-<br />
|<b>sec-review-sched</b><br />
| Security review tasks have been scheduled, if this is a full security review the date of the scheduled review will be present in the security notes.<br />
|<br />
|-<br />
|<b>sec-review-unnecessary</b><br />
| After triage it was felt the feature needed no review or security actions. <br />
|<br />
|-<br />
| <b>Security health: <blank></b><br />
| There are no notes or status is unknown.<br />
| Color: <None><br />
|-<br />
| <b>Security health: OK</b><br />
| The tasks are on schedule or completed and are considered non-blocking.<br />
| {{StatusHealthy|status=Color: Green}}<br />
|-<br />
| <b>Security health: Blocked</b><br />
| Some aspect of the security review has given cause to block the feature from further work or landing. The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusBlocked|status=Color: Yellow}}<br />
|-<br />
| <b>Security health: At Risk</b><br />
| Some aspect of the security review may cause the feature to be blocked or put the feature at risk of being off schedule.The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusAtRisk|status=Color: Red}}<br />
|-<br />
| <b>Security health: Assigned</b><br />
| Security tasks have been assigned to a member of the team to followup. The name of this resource will be in the security notes.<br />
| {{StatusAssigned|status=Color: Teal}}<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1223047User:Tritter/Working/Client Security Severity Ratings2020-02-03T17:38:43Z<p>Tritter: </p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
* Bugs relating to Firefox for iOS where the vulnerability is actually in Apple's WebKit<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
|}<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Web_Security_Severity_Ratings&diff=1223044User:Tritter/Working/Web Security Severity Ratings2020-02-03T14:56:02Z<p>Tritter: Created page with "__TOC__ ==Severity Ratings == In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that coul..."</p>
<hr />
<div>__TOC__<br />
<br />
==Severity Ratings ==<br />
<br />
In all cases, the severity of server and web application bugs is dependent on the critically of the service and the value of the data that could be compromised. Thus while the table below provides <i>very</i> broad guideliens, they cannot be directly used to determine the severity of a bug absent the consideration of the affected service. <br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Really bad stuff.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* XSS (Stored)<br />
* CSRF<br />
* Remoce Code Execution<br />
* Authentication Flaws (which lead to account compromise)<br />
* Session Management Flaws (which lead to account compromise) <br />
|}<br />
<br />
;'''sec-high''': Typically, sec-high issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Cross-site Scripting (XSS)<br />
* XSS (Reflected)<br />
* Failure to use TLS where needed to ensure confidential/security <br />
|}<br />
<br />
;'''sec-moderate''': Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone). The lack of standard defense in depth techniques and security controls.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Detection of arbitrary local files<br />
* Missing Additional Security Controls (x-frame options, SECURE/HTTPOnly flags, etc)<br />
* Error Handling Issues <br />
|}<br />
;'''sec-low''': Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls <br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Lack of proper input validation (not resulting in XSS or injection)<br />
* Content spoofing (non-html) <br />
|}<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* XXX<br />
|}<br />
;'''sec-incident''': Issues resulting in an incident response or 'chemspill' actions by the security team.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-incident Examples:''<br />
|-<br />
|<br />
* Server compromise<br />
|}<br />
|}<br />
<br />
=== wsectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|wsec-authentication || Website or server authentication security issues (lockouts, password policy, etc)<br />
|-<br />
|wsec-authorization || web/server authorization security issues<br />
|-<br />
|wsec-cookie || Cookie related errors (HTTPOnly / Secure Flag, incorrect domain / path)<br />
|-<br />
|wsec-crossdomain || Issue such as x-frame-options, crossdomain.xml, cross site sharing settings<br />
|-<br />
|wsec-crypto || Crypto related items such as password hashing<br />
|-<br />
|wsec-csrf || Cross-Site Request Forgery (CSRF) bugs in server products<br />
|-<br />
|wsec-disclosure || Disclosure of sensitive data, personal information, etc from a web service<br />
|-<br />
|wsec-dos || Used to denote web server Denial of Service bugs. For similar bugs in client software please use csectype-dos instead.<br />
|-<br />
|wsec-errorhandling || Any error handling issue<br />
|-<br />
|wsec-impersonation || Impersonation / Spoofing attacks (UI Redress, etc) <br />
|-<br />
|wsec-injection || Injection attacks other than SQLi or XSS <br />
|-<br />
|wsec-input || Failure to perform input validation. Most often you will probably use the xss tag instead<br />
|-<br />
|wsec-logging || Logging issues such as requests for CEF log points.<br />
|-<br />
|wsec-other || web/server security issues that don't fit into other categories<br />
|-<br />
|wsec-session || Issues related to sesson management (Session fixation, etc)<br />
|-<br />
|wsec-sqli || SQL Injection <br />
|-<br />
|wsec-ssrf || Server Side Request Forgery (SSRF) bugs in server products. CWE-918<br />
|-<br />
|wsec-xss || Cross-Site Scripting (XSS) bugs in server products<br />
|-<br />
|}<br />
<br />
=== opsectype- Keywords ===<br />
<br />
opsectype- keywords are assigned to bugs relating to Operations Security (Mozilla owned & operated severs and services)<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
| opsec-access<br />
| The identified issue is an access violation.<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Whiteboard Tags<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<strike><b>sec-assigned:UserAlias</b></strike> <b>depricated for sec-review? flag with alias</b><br />
|This designates the assigned security resource that is accountable for actions to be taken on the designated item. When possible the bug will be assigned to the security contact for action. This will be used when that is not possible or practical.<br />
|sec-review?:curtisk@blah.bah indicates that curtisk is the accountable party for action<br />
|-<br />
|<b>[Q2]</b><br />
|This designates a bug as being identified as a request to be done or targeted for a given operational quarter. If no year is given it is for the current year.<br />
|[Q2] indicates second quarter of the current calendar year, [Q1-2013] would be used to indicate a target for an upcoming quarter that has not occurred. <br />
|-<br />
|<b>[k90]</b><br />
|This designates a bug as being part of the Kilimanjaro effort so that it can be tracked, triaged and given appropriate priority and attention.<br />
|<br />
|-<br />
|<b>[basecamp]</b><br />
|This designates a bug as being part of the basecamp sub effort of the Kilimanjaro effort.<br />
|<br />
|- <br />
|<b>[fennec]</b><br />
|This designates a bug as being a critical bug for the efforts around our mobile browser project. This could be combined with either the [k9o] or [basecamp] tags as a bug could be part of both.<br />
|<br />
|-<br />
|<b>[triage needed]</b><br />
|Used to mark a bug for weekly triage meeting.<br />
|<br />
|-<br />
|<strike><b>[pending secreview]</b></strike> deprecated<br />
| Indicates a secreview or tasks related to said review are yet to be completed.<br />
|<br />
|-<br />
|<b>[start mm/dd/yyyy][target mm/dd/yyyy]</b><br />
|This indicates that expected dates to start and complete work on a given review or security bug.<br />
|[start 01/29/2013][target 02/09/2013] indicates work will start on 29-Jan and expected target for completion on 09-Feb<br />
|-<br />
|<strike><b>[completed secreview]</b></strike> deprecated<br />
| Indicates the given secreview or related tasks have been completed<br />
|<br />
|-<br />
|<b>mentorship</b><br />
| Indicates that a given bug is part of our security mentorship program. The assignee of said bug is the Mozilla mentor for such a bug.<br />
|<br />
|-<br />
|<strike><b>[score:##]</b></strike> deprecated<br />
|This indicates the relative severity score for risk rating bugs per the calculator at https://people.mozilla.com/~ckoenig/<br />
|[score:30:moderate] shows that the issue has a numerical score of 30 and a severity of moderate.<br />
|-<br />
|<b>[Web]</b><br />
|Indicates an item related to our Web properties<br />
|<br />
|-<br />
|<b>u= c= p=</b><br />
|These items are used to allow bugs to be tracked by scrumbu.gs for work tracking ([http://scrumbu.gs/help/ more info]).<br />
|<br />
|-<br />
|<b>s=</b><br />
|This tag is used in conjunction with the scrumbu.gs tags above to indicate which sprint a given bug has been assigned.<br />
|s=13q4.1 indicates the bug is in the year 2013, 4th quarter and sprint 1. Each sprint is 2 weeks long and it's calendar dates can be tracked on scrumbu.gs<br />
|-<br />
|}<br />
<br />
=== Feature Page Codes ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Feature Page Codes<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
! style="width:5%" | Examples<br />
|-<br />
|<b>sec-review-needed</b><br />
|A security review is needed for the feature, this could mean a variety of things. If there is no <username> in the notes then a full review needs to be scheduled, if a <username> is present than that person will follow-up with the feature team on whatever task is needed.<br />
|<br />
|-<br />
|<b>sec-review-complete</b><br />
|The security review / actions desired have been completed. This will result in a link to the notes from security actions or a note from the assigned resource.<br />
|<br />
|-<br />
|<b>sec-review-active</b><br />
| There are active tasks associated with the review that are yet to be completed in order for the review to be seen as completed. These will be captured in the "Action Items" section of the review notes.<br />
|<br />
|-<br />
|<b>sec-review-sched</b><br />
| Security review tasks have been scheduled, if this is a full security review the date of the scheduled review will be present in the security notes.<br />
|<br />
|-<br />
|<b>sec-review-unnecessary</b><br />
| After triage it was felt the feature needed no review or security actions. <br />
|<br />
|-<br />
| <b>Security health: <blank></b><br />
| There are no notes or status is unknown.<br />
| Color: <None><br />
|-<br />
| <b>Security health: OK</b><br />
| The tasks are on schedule or completed and are considered non-blocking.<br />
| {{StatusHealthy|status=Color: Green}}<br />
|-<br />
| <b>Security health: Blocked</b><br />
| Some aspect of the security review has given cause to block the feature from further work or landing. The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusBlocked|status=Color: Yellow}}<br />
|-<br />
| <b>Security health: At Risk</b><br />
| Some aspect of the security review may cause the feature to be blocked or put the feature at risk of being off schedule.The reasons will be listed in the security notes or linked to a larger review outcome for follow-up.<br />
| {{StatusAtRisk|status=Color: Red}}<br />
|-<br />
| <b>Security health: Assigned</b><br />
| Security tasks have been assigned to a member of the team to followup. The name of this resource will be in the security notes.<br />
| {{StatusAssigned|status=Color: Teal}}<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
! Flags<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1223043User:Tritter/Working/Client Security Severity Ratings2020-02-03T14:55:19Z<p>Tritter: </p>
<hr />
<div>__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
* Bugs relating to Firefox for iOS where the vulnerability is actually in Apple's WebKit<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
;'''sec-incident''': Issues resulting in an incident response or 'chemspill' actions by the security team.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-incident Examples:''<br />
|-<br />
|<br />
* Server compromise<br />
* Code issues that would cause client code to be respun.<br />
|}<br />
|}<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working/Client_Security_Severity_Ratings&diff=1223042User:Tritter/Working/Client Security Severity Ratings2020-02-03T14:54:56Z<p>Tritter: Created page with "[New Client Severity Page] __TOC__ The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla..."</p>
<hr />
<div>[New Client Severity Page]<br />
<br />
__TOC__<br />
<br />
The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties, see this corresponding page. For details about the bug bounty for the Firefox browser, and specific other applications, see [this page]. For details about the bug bounty for Mozilla Servers and Web Properties, see [this page].<br />
<br />
==Severity Ratings ==<br />
<br />
Severity ratings are used to indicate how severe we beleive a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Severity Ratings & Examples<br />
|-<br />
|<br />
The following items are keywords for the severity of an issue.<br />
<br />
;'''sec-critical''': Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-critical Examples:''<br />
|-<br />
|<br />
* Vulnerabilities actively exploited or publicly disclosed<br />
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit <br />
|}<br />
<br />
;'''sec-high''': High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.)<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-high Examples:''<br />
|-<br />
|<br />
* Theft of arbitrary files from local system<br />
* Spoofing of full URL bar or bypass of SSL integrity checks<br />
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content<br />
* JavaScript injection into browser chrome or other origins<br />
* Failure to use TLS where needed to ensure confidential/security <br />
* Memory corruption leading to a limited or arbitrary memory read or write.<br />
* Proxy bypass<br />
* Disclosure of browsing history<br />
* Overflows resulting in native code execution <br />
* Launching of arbitrary local application with provided arguments<br />
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue<br />
|}<br />
<br />
;'''sec-moderate''': Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-moderate Examples:''<br />
|-<br />
|<br />
* Disclosure of OS username<br />
* Disclosure of browsing history through effecient and fast timing side channels<br />
* Detection of arbitrary local files<br />
* Launching of arbitrary local application without arguments<br />
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future<br />
|}<br />
;'''sec-low''': Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-low Examples:''<br />
|-<br />
|<br />
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration<br />
* Identification of users by profiling browsing behavior.<br />
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages<br />
|}<br />
;'''Mitigating Circumstances''':<br />
If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. <br />
<br />
As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.<br />
|}<br />
<br />
==Additional Status Codes, Whiteboard Tracking Tags & Flags==<br />
<br />
If a potential security issue has not yet been assigned a severity rating, or a rating is not appropriate, the keywords may instead contain one of the following security status codes.<br />
<br />
=== Alternate Keywords ===<br />
<br />
Often none of the above severity ratings apply to a bug, because it is not a vulnerability but nonetheless is security sensitive and needs to be kept private. These keywords apply to those.<br />
<br />
While we request that only the security team assign <u>sec-high</u> and similar ratings, we encourage you tag things <u>sec-want</u> and <u>sec-audit</u> if you feel it applies.<br />
<br />
{| class="wikitable collapsible" style="width: 100%"<br />
! Alternate Keywords & Examples<br />
|-<br />
|<br />
;'''sec-other''': sec-other is a bit of a catch-all bucket used for bugs that are not exploitable security issues but need to be kept confidential to protect sensitive information.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-other Examples:''<br />
|-<br />
|<br />
* Gaps in fuzzing coverage to be addressed<br />
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)<br />
* Bugs relating to Firefox for iOS where the vulnerability is actually in Apple's WebKit<br />
|}<br />
<br />
;'''sec-audit''': Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-audit Examples:''<br />
|-<br />
|<br />
* Look for pattern x in library y<br />
* Audit file z for string buffer abuse.<br />
|}<br />
<br />
;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-vector Examples:''<br />
|-<br />
|<br />
* Bugs in plugins<br />
* Bugs in system libraries used by Firefox<br />
|}<br />
;'''sec-want''': New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-want Examples:''<br />
|-<br />
|<br />
* User interface refinements<br />
* Security-relevant standards improvements or implementation<br />
* Support for new types of authentication <br />
* Code refactoring / cleanup<br />
|}<br />
;'''sec-incident''': Issues resulting in an incident response or 'chemspill' actions by the security team.<br />
<br />
{| class="wikitable collapsible " style="width: 100%"<br />
! ''sec-incident Examples:''<br />
|-<br />
|<br />
* Server compromise<br />
* Code issues that would cause client code to be respun.<br />
|}<br />
|}<br />
<br />
=== csectype- Keywords ===<br />
<br />
csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign <u>sec-high</u> and similar ratings, if you feel you can identify the type of a security bug <b><u>we encourage you to classify it yourself.</u></b><br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)<br />
|-<br />
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product. <br />
|-<br />
|csectype-dos || Used to tag client Denial of Service bugs. For web server denial of service bugs please use wsec-dos as these tend to be more severe.<br />
|-<br />
|csectype-intoverflow || client security issues due to integer overflow <br />
|-<br />
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions<br />
|-<br />
|csectype-other || client security issues that don't fit into other categories <br />
|-<br />
|csectype-priv-escalation || client privilege escalation security issues <br />
|-<br />
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example). <br />
|-<br />
|csectype-uaf || client security issues due to a use-after-free<br />
|-<br />
|csectype-ui-redress || client security issues due to UI Redress attacks, either site-on-site ("clickjacking" and friends) or manipulation of the browser UI to fool users into taking the wrong action. <br />
|-<br />
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.<br />
|-<br />
|csectype-uninitialized || client security issues due to use of uninitialized memory <br />
|-<br />
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)<br />
|-<br />
|}<br />
<br />
=== Whiteboard Tags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Code <br />
! style="width:10%"| Description<br />
|-<br />
|<b>[bad-ram?]</b><br />
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.<br />
|-<br />
|<b>[pixel-stealing]</b><br />
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.<br />
|-<br />
|<b>[fingerprinting]</b><br />
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.<br />
|-<br />
|}<br />
<br />
=== Flags ===<br />
<br />
{| style="width: 800px;" class="wikitable collapsible fullwidth-table"<br />
|-<br />
! style="width:5%" | Flag <br />
! style="width:10%"| Description<br />
! style="width:5%" | Settings<br />
|-<br />
| sec-review<br />
| Security review - Requesting action from the security assurance team or showing the results of said action<br />
| <br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Request for the security team to review the requested bug for action<br />
|-<br />
|'+'|| Bug has been reviewed, actions are done and the security team has no further concerns at this time<br />
|-<br />
|'-'|| But has been reviewed and found to be deficient in a security metric that should be mitigated<br />
|-<br />
|}<br />
|-<br />
| sec-bounty<br />
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and a payment will be made<br />
|-<br />
|'-'|| Bug does not meet criteria and a payment will ''not'' be made<br />
|-<br />
|}<br />
|-<br />
| sec-bounty-hof<br />
| Shows the status of a bug with regards to a bounty hall of fame entry<br />
|<br />
{|class="wikitable fullwidth-table"<br />
|-<br />
! style="width:5%" | Setting <br />
! style="width:10%"| Description<br />
|-<br />
|'?'|| Bug is nominated for review by the bounty committee<br />
|-<br />
|'+'|| Bug has been accepted and an entry in the hall of fame will occur<br />
|-<br />
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made<br />
|-<br />
|}<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working&diff=1223041User:Tritter/Working2020-02-03T14:52:28Z<p>Tritter: </p>
<hr />
<div>This is where I place in-progress pages I am revising. They are IN PROGRESS and NOT FINAL.<br />
<br />
[[User:Tritter/Working/Client Security Severity Ratings]]<br />
<br />
[[User:Tritter/Working/Web Security Severity Ratings]]</div>Tritterhttps://wiki.mozilla.org/index.php?title=User:Tritter/Working&diff=1223040User:Tritter/Working2020-02-03T14:52:11Z<p>Tritter: Created page with "This is where I place in-progress pages I am revising. User:Tritter/Working/Client Security Severity Ratings User:Tritter/Working/Web Security Severity Ratings"</p>
<hr />
<div>This is where I place in-progress pages I am revising.<br />
<br />
[[User:Tritter/Working/Client Security Severity Ratings]]<br />
<br />
[[User:Tritter/Working/Web Security Severity Ratings]]</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1221990Security/Firefox/Security Bug Life Cycle/Security Advisories2020-01-07T19:46:04Z<p>Tritter: </p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'<br />
* Check if there are no community members on the rollup, and if so, remove that bit<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)<br />
<br />
=== Release ===<br />
<br />
Once CVEs are assigned, the yml files are checked into git and staged in the private https://github.com/mozilla/foundation-security-advisories-private/ repo. Release management will pull from this repo and commit it to the public https://github.com/mozilla/foundation-security-advisories/ repo which will make them live on the site in moments.</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1221988Security/Firefox/Security Bug Life Cycle/Security Advisories2020-01-07T19:41:38Z<p>Tritter: </p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'<br />
* Check if there are no community members on the rollup, and if so, remove that bit<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)</div>Tritterhttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1220848ReleaseEngineering/DisposableProjectRepositories2019-12-02T20:29:18Z<p>Tritter: /* BOOKING SCHEDULE */</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|1518167}}) to VCS to reset the repo for you. You can specify the source repository and target revision to use, or default to mozilla-central:tip. '''Ask that they run the `hgmo-reset-twig.yml` Ansible playbook found in version-control-tools to accomplish this'''.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* After Developer Services runs the reset, they will also notify the teams who operate the automation, so they can adjust their schedulers to recognize the reset. If you don't see the expected builds, check with the automation teams to ensure their reset occurred.<br />
* Sit back and watch your builds and test results roll in (eg [https://treeherder.mozilla.org/#/jobs?repo=birch Birch], [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar], [https://treeherder.mozilla.org/#/jobs?repo=larch Larch], [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]). <br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| {{bug|1537741}}<br />
| peterv@mozilla.com<br />
| fission, :peterv<br />
| 2019-03-21 - 2019-08-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|1364561}}<br />
| jgraham@mozilla.com<br />
| wpt-sync<br />
| 2017-09-06 - 2017-12-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| {{bug|1554228}}<br />
| vporof@mozilla.com<br />
| :vp, Browser Architecture usage<br />
| 2019-06-01 - 2019-08-01<br />
|<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=holly Holly]<br />
| {{bug|1599905}}<br />
| jewilde@mozilla.com, tom@mozilla.com<br />
| <-<br />
| 2019-12-02 - 2020-04-02<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1322426}} socket process isolation<br />
| hbambas@mozilla.com<br />
| necko, :mayhemer<br />
| 2018-08-20 - 2020-08-20<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| mhowell@mozilla.com, rstrong@mozilla.com<br />
| mhowell, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|137122}}<br />
| dmose@mozilla.org<br />
| :dmose,:k88hudson,:Mardak,:ursula green up activity-stream in prep for landing<br />
| 2017-02-05 - 2017-06-10<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| disabled<br />
| disabled<br />
| disabled<br />
| DO NOT USE - https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1259143}}<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| Release promotion<br />
| 2016-03-23 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1426132}}<br />
| release@mozilla.com<br />
| tc release promotion<br />
| 2017-12-19 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| {{bug|1397773}}<br />
| aki@mozilla.com<br />
| tc release promotion<br />
| 2017-10-02 - indefinite<br />
|-<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1220847ReleaseEngineering/DisposableProjectRepositories2019-12-02T20:29:00Z<p>Tritter: /* BOOKING SCHEDULE */</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|1518167}}) to VCS to reset the repo for you. You can specify the source repository and target revision to use, or default to mozilla-central:tip. '''Ask that they run the `hgmo-reset-twig.yml` Ansible playbook found in version-control-tools to accomplish this'''.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* After Developer Services runs the reset, they will also notify the teams who operate the automation, so they can adjust their schedulers to recognize the reset. If you don't see the expected builds, check with the automation teams to ensure their reset occurred.<br />
* Sit back and watch your builds and test results roll in (eg [https://treeherder.mozilla.org/#/jobs?repo=birch Birch], [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar], [https://treeherder.mozilla.org/#/jobs?repo=larch Larch], [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]). <br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| {{bug|1537741}}<br />
| peterv@mozilla.com<br />
| fission, :peterv<br />
| 2019-03-21 - 2019-08-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|1364561}}<br />
| jgraham@mozilla.com<br />
| wpt-sync<br />
| 2017-09-06 - 2017-12-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| {{bug|1554228}}<br />
| vporof@mozilla.com<br />
| :vp, Browser Architecture usage<br />
| 2019-06-01 - 2019-08-01<br />
|<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=twig Twig]<br />
| {{bug|1599905}}<br />
| jewilde@mozilla.com, tom@mozilla.com<br />
| <-<br />
| 2019-12-02 - 2020-04-02<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1322426}} socket process isolation<br />
| hbambas@mozilla.com<br />
| necko, :mayhemer<br />
| 2018-08-20 - 2020-08-20<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| mhowell@mozilla.com, rstrong@mozilla.com<br />
| mhowell, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|137122}}<br />
| dmose@mozilla.org<br />
| :dmose,:k88hudson,:Mardak,:ursula green up activity-stream in prep for landing<br />
| 2017-02-05 - 2017-06-10<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| disabled<br />
| disabled<br />
| disabled<br />
| DO NOT USE - https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1259143}}<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| Release promotion<br />
| 2016-03-23 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1426132}}<br />
| release@mozilla.com<br />
| tc release promotion<br />
| 2017-12-19 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| {{bug|1397773}}<br />
| aki@mozilla.com<br />
| tc release promotion<br />
| 2017-10-02 - indefinite<br />
|-<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1220832ReleaseEngineering/DisposableProjectRepositories2019-12-02T18:21:53Z<p>Tritter: /* BOOKING SCHEDULE */</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|1518167}}) to VCS to reset the repo for you. You can specify the source repository and target revision to use, or default to mozilla-central:tip. '''Ask that they run the `hgmo-reset-twig.yml` Ansible playbook found in version-control-tools to accomplish this'''.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* After Developer Services runs the reset, they will also notify the teams who operate the automation, so they can adjust their schedulers to recognize the reset. If you don't see the expected builds, check with the automation teams to ensure their reset occurred.<br />
* Sit back and watch your builds and test results roll in (eg [https://treeherder.mozilla.org/#/jobs?repo=birch Birch], [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar], [https://treeherder.mozilla.org/#/jobs?repo=larch Larch], [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]). <br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| {{bug|1537741}}<br />
| peterv@mozilla.com<br />
| fission, :peterv<br />
| 2019-03-21 - 2019-08-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|1364561}}<br />
| jgraham@mozilla.com<br />
| wpt-sync<br />
| 2017-09-06 - 2017-12-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| {{bug|1554228}}<br />
| vporof@mozilla.com<br />
| :vp, Browser Architecture usage<br />
| 2019-06-01 - 2019-08-01<br />
|<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1322426}} socket process isolation<br />
| hbambas@mozilla.com<br />
| necko, :mayhemer<br />
| 2018-08-20 - 2020-08-20<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| mhowell@mozilla.com, rstrong@mozilla.com<br />
| mhowell, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|137122}}<br />
| dmose@mozilla.org<br />
| :dmose,:k88hudson,:Mardak,:ursula green up activity-stream in prep for landing<br />
| 2017-02-05 - 2017-06-10<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=twig Twig]<br />
| {{bug|1599905}}<br />
| jewilde@mozilla.com, tom@mozilla.com<br />
| <-<br />
| 2019-12-02 - 2020-04-02<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| disabled<br />
| disabled<br />
| disabled<br />
| DO NOT USE - https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1259143}}<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| Release promotion<br />
| 2016-03-23 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1426132}}<br />
| release@mozilla.com<br />
| tc release promotion<br />
| 2017-12-19 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| {{bug|1397773}}<br />
| aki@mozilla.com<br />
| tc release promotion<br />
| 2017-10-02 - indefinite<br />
|-<br />
|}</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1220808Security/Firefox/Security Bug Life Cycle/Security Advisories2019-12-02T16:01:15Z<p>Tritter: /* Review it yourself */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
'''''Note: This document is going to be incomplete until Tom does the 71 security advisories, and then he can refine the page.'''''<br />
<br />
The previous [https://docs.google.com/document/d/1S5Gs-CSEvr4X4TiuWXrNP4wXxyjZJTO-Q00-PBZFasQ/edit# document is here] and this page will eventually supplant it, but it's not done yet.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* Function names and objects should be enclosed with &lt;code&gt; tags<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'<br />
* Check if there are no community members on the rollup, and if so, remove that bit<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1220807Security/Firefox/Security Bug Life Cycle/Security Advisories2019-12-02T16:00:55Z<p>Tritter: /* Get review */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
'''''Note: This document is going to be incomplete until Tom does the 71 security advisories, and then he can refine the page.'''''<br />
<br />
The previous [https://docs.google.com/document/d/1S5Gs-CSEvr4X4TiuWXrNP4wXxyjZJTO-Q00-PBZFasQ/edit# document is here] and this page will eventually supplant it, but it's not done yet.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Review it yourself ===<br />
<br />
* We use the past tense when writing about vulnerabilities<br />
* The titles of bugs do *not* use Title Case, they use Sentence Case.<br />
* Function names and objects should be enclosed with <code> tags<br />
* JavaScript not javascript<br />
* use-after-free not 'use after free'<br />
* Check if there are no community members on the rollup, and if so, remove that bit<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1220279Security/Firefox/Security Bug Life Cycle/Security Advisories2019-11-14T20:07:34Z<p>Tritter: /* Generate and edit the YML File */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
'''''Note: This document is going to be incomplete until Tom does the 71 security advisories, and then he can refine the page.'''''<br />
<br />
The previous [https://docs.google.com/document/d/1S5Gs-CSEvr4X4TiuWXrNP4wXxyjZJTO-Q00-PBZFasQ/edit# document is here] and this page will eventually supplant it, but it's not done yet.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using [https://github.com/tomrittervg/secadv/blob/master/gen_yml.py this script], generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)</div>Tritterhttps://wiki.mozilla.org/index.php?title=Security/Firefox/Security_Bug_Life_Cycle/Security_Advisories&diff=1220278Security/Firefox/Security Bug Life Cycle/Security Advisories2019-11-14T20:06:24Z<p>Tritter: /* Tag them */</p>
<hr />
<div>== Background ==<br />
<br />
This page documents the process to create security advisories for Firefox. If you're looking for what the advisories actually are; you want to go to https://www.mozilla.org/en-US/security/advisories/<br />
<br />
The goal is that with this document, and the scripts, anyone with the appropriate access can produce advisories. Presently Tom Ritter does Security Advisories, who inherited it from Al Billings.<br />
<br />
'''''Note: This document is going to be incomplete until Tom does the 71 security advisories, and then he can refine the page.'''''<br />
<br />
The previous [https://docs.google.com/document/d/1S5Gs-CSEvr4X4TiuWXrNP4wXxyjZJTO-Q00-PBZFasQ/edit# document is here] and this page will eventually supplant it, but it's not done yet.<br />
<br />
== Process ==<br />
<br />
=== Determine what bugs will get advisories ===<br />
<br />
==== Criteria ====<br />
<br />
* All client bugs that ship in Firefox reported in Bugzilla with a sec-critical, sec-high, sec-moderate, or sec-low rating are normally included in an advisory. <br />
* Exceptions are occasionally made for sec-low rated issues, especially internal reports, deemed too minor for advisory inclusion.<br />
* Internally found memory corruption issues, usually found by developers or members of the fuzzing team, are included in a “roll-up” advisory that is a list of internally found and fixed issues affecting the previous release that were reported by employees or longtime community members. This roll up does not get a detailed advisory but is simply a list of internally found issues.<br />
* Externally reported security bugs with security ratings always receive an advisory outside of the above parameters if they affected a shipped Firefox release.<br />
* Internally-found vulnerabilities that are not simple memory corruption usually get a separate advisory and don't go in the "roll-up".<br />
* Vulnerabilities that only existed in Nightly or Beta versions do not need an advisory.<br />
<br />
==== Tag them ====<br />
<br />
# Query for bugs using the status-firefoxXX (with the release number) flag that are marked as “verified” or “fixed” that also do not have the status-firefoxXY flag for the previous release set to “fixed”, “verified”, “unaffected”, or “disabled” in bugzilla. Additionally, we query on whether the bugs have a “sec-” keyword or are in any security group in Bugzilla. [https://github.com/tomrittervg/secadv/blob/master/gen_queries.py I use a script that generates the bugzilla query for a given version.] For example <tt>./gen_queries.py 71</tt> or <tt>./gen_queries.py 71 -v</tt><br />
# For each bug, decide on an advisory, marking it with a whiteboard tag. A missing whiteboard tag helps us notice when new fixes land late in the release cycle, and in the future the whiteboard tag is useful for tracking when a vulnerability received an advisory.<br />
## The whiteboard of the bug is tagged with [adv-mainXX+], [adv-mainXX-], [adv-ESRXX.X+], or [adv-ESRXX.X-] to mark whether an advisory is being created (a ‘+’) or explicitly not being created (a ‘-’) for a given Firefox or Firefox ESR release.<br />
## [adv-mainXX+r] (and [adv-esrXX+r]) is used to mark bugs that will go into the roll-up advisory.<br />
<br />
=== Write the advisories ===<br />
<br />
On each bug granted an advisory (excepting the roll-up bugs) - an attachment is added to the bug with a description of 'advisory.txt'. The file should contain:<br />
<br />
Title<br />
Reporter<br />
<br />
Description<br />
<br />
for example:<br />
<br />
Memory corruption when processing WebRTC messages<br />
John Doe<br />
<br />
When receiving a foobar message, an attacker could specify in incorrect number of gordons, leading to memory corruption.<br />
<br />
Advisories are written in the past tense. Typically they're somewhat vague, but they don't have to be. Anyone is allowed to write an advisory for a bug if they feel they can do so; however, only one non-obsolete advisory.txt should be attached when the yml creation is performed.<br />
<br />
=== Generate and edit the YML File ===<br />
<br />
Using TODOXXX this script, generate a first-pass at the .yml file.<br />
<br />
Go through and review it. For the first pass, I recommend edits be made directly on the advisory.txt attachments. However, certain edits will not be possible to do there. Specifically: adding (or removing) the description field from the top of the document and editing the list of reporters in the rollup advisory.<br />
<br />
=== Get review ===<br />
<br />
Confirm with dveditz ahead of time that he can take a look with a turn-around time of 2-3 days, and then send the yml files to him about a week or 8 days before the release date. Make edits.<br />
<br />
Following that round, send the .yml files to the security-group list and solicit more feedback. This should be done about 4 days before the release.<br />
<br />
=== Assign CVEs ===<br />
<br />
Typically done a day or two before the release, assign CVEs to the bugs in bugzilla, and in the yml file. TODOXXX - this should be automated. (I'm thinking - assign them using a google apps script that interfaces with the spreadsheet, regenerate the yml and diff across any manual edits.)<br />
<br />
A noteworthy item is that issues that already have had a CVE assigned - for example because it's an upstream bug - should get a '''feed: false''' in the advisory, after reporter.<br />
<br />
A CVE ID from Mitre is assigned from [https://docs.google.com/spreadsheets/d/14rI7jdL23HHJ5VOpVJhV_zc_bp2InrXlKD_vap9oec0/edit our CVE pool] of numbers as an “alias” in Bugzilla and the CVE Pool sheet is updated to include the bug number and title on the listing for the assigned CVE ID.<br />
<br />
The CVE ID is unique per bug except for the internal roll-up advisories, which use one CVE ID for a list of bugs. (The CVE assignment process can be complicated because Mitre imposes many rules on CVE assignment and requires communication back in specified data formats when CVEs are assigned. Failure to follow this process can result in Mitre refusing to hand out additional CVE IDs for use.)</div>Tritter