Changes

Jump to: navigation, search

Security Severity Ratings/Client

11,403 bytes added, 18:36, 2 March 2020
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,..."
__TOC__

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].

==Severity Ratings ==

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.

{| class="wikitable collapsible" style="width: 100%"
! Severity Ratings & Examples
|-
|
The following items are keywords for the severity of an issue.

;'''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.
{| class="wikitable collapsible " style="width: 100%"
! ''sec-critical Examples:''
|-
|
* Vulnerabilities actively exploited or publicly disclosed
* Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit
|}

;'''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.)
{| class="wikitable collapsible " style="width: 100%"
! ''sec-high Examples:''
|-
|
* Theft of arbitrary files from local system
* Spoofing of full URL bar or bypass of SSL integrity checks
* Memory read that results in data being written into an inert container (ie string or image) that is subsequently accessible to content
* JavaScript injection into browser chrome or other origins
* Failure to use TLS where needed to ensure confidential/security
* Memory corruption leading to a limited or arbitrary memory read or write.
* Sandbox escapes
* Proxy bypass
* Disclosure of browsing history
* Overflows resulting in native code execution
* Launching of arbitrary local application with provided arguments
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue
|}

;'''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.
{| class="wikitable collapsible " style="width: 100%"
! ''sec-moderate Examples:''
|-
|
* Disclosure of OS username
* Disclosure of browsing history through effecient and fast timing side channels
* Detection of arbitrary local files
* Launching of arbitrary local application without arguments
* The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk
|}
;'''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.

{| class="wikitable collapsible " style="width: 100%"
! ''sec-low Examples:''
|-
|
* Detection of a previous visit to a specific site, or when the affected site has a certain configuration
* Identification of users by profiling browsing behavior.
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages
* Most Denial of Service vulnerabilities, such as those requiring a browser restart
|}
;'''Mitigating Circumstances''':
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.

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.
|}

==Additional Status Codes, Whiteboard Tracking Tags & Flags==

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.

=== Alternate Keywords ===

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.

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.

{| class="wikitable collapsible" style="width: 100%"
! Alternate Keywords & Examples
|-
|
;'''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.
{| class="wikitable collapsible " style="width: 100%"
! ''sec-other Examples:''
|-
|
* Gaps in fuzzing coverage to be addressed
* Bugs submitted by a user where the discussion is dependent on that user's browsing behavior (and cannot be effectively redacted)
|}

;'''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.
{| class="wikitable collapsible " style="width: 100%"
! ''sec-audit Examples:''
|-
|
* Look for pattern x in library y
* Audit file z for string buffer abuse.
|}

;'''sec-vector''': Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users.
{| class="wikitable collapsible " style="width: 100%"
! ''sec-vector Examples:''
|-
|
* Bugs in plugins
* Bugs in system libraries used by Firefox
|}
;'''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.

{| class="wikitable collapsible " style="width: 100%"
! ''sec-want Examples:''
|-
|
* User interface refinements
* Security-relevant standards improvements or implementation
* Support for new types of authentication
* Code refactoring / cleanup
|}
|}

A historical keyword is <b>sec-incident</b>, which is no longer used.

=== csectype- Keywords ===

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>

{| style="width: 800px;" class="wikitable collapsible fullwidth-table"
|-
! style="width:5%" | Code
! style="width:10%"| Description
|-
|csectype-bounds || client security issues due to incorrect boundary conditions (read or write)
|-
|csectype-disclosure || Disclosure of sensitive user data, personal information, etc in a client product.
|-
|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.
|-
|csectype-intoverflow || client security issues due to integer overflow
|-
|csectype-jit || client security issues due to jit miscompilation or similar
|-
|csectype-oom || A client crash or hang that occurs in Out Of Memory conditions
|-
|csectype-other || client security issues that don't fit into other categories
|-
|csectype-priv-escalation || client privilege escalation security issues
|-
|csectype-sop || violations of the client Same Origin Policy (Universal-XSS bugs, for example).
|-
|csectype-uaf || client security issues due to a use-after-free
|-
|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.
|-
|csectype-undefined || Bugs--or potential bugs--due to undefined compiler behavior.
|-
|csectype-uninitialized || client security issues due to use of uninitialized memory
|-
|csectype-wildptr || client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)
|-
|}

=== Whiteboard Tags ===

{| style="width: 800px;" class="wikitable collapsible fullwidth-table"
|-
! style="width:5%" | Code
! style="width:10%"| Description
|-
|<b>[bad-ram?]</b>
|This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.
|-
|<b>[pixel-stealing]</b>
|This indicates vulnerabilities related to side-channel attacks on cross-origin resources.
|-
|<b>[fingerprinting]</b>
|This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.
|-
|}

=== Flags ===

{| style="width: 800px;" class="wikitable collapsible fullwidth-table"
|-
! style="width:5%" | Flag
! style="width:10%"| Description
! style="width:5%" | Settings
|-
| sec-bounty
| Shows the status of a bug with regards to a bounty payout per our bounty guidlines
|
{|class="wikitable fullwidth-table"
|-
! style="width:5%" | Setting
! style="width:10%"| Description
|-
|'?'|| Bug is nominated for review by the bounty committee
|-
|'+'|| Bug has been accepted and a payment will be made
|-
|'-'|| Bug does not meet criteria and a payment will ''not'' be made
|-
|}
|-
| sec-bounty-hof
| Shows the status of a bug with regards to a bounty hall of fame entry
|
{|class="wikitable fullwidth-table"
|-
! style="width:5%" | Setting
! style="width:10%"| Description
|-
|'?'|| Bug is nominated for review by the bounty committee
|-
|'+'|| Bug has been accepted and an entry in the hall of fame will occur
|-
|'-'|| Bug does not meet criteria and a hall of fame entry will ''not'' be made
|-
|}
|}
121
edits

Navigation menu