View source for Security Severity Ratings/Proposals

= Proposals for Changing Rating Guidelines for Security Bugs =
David Bolter and Al were looking for guidelines on common scenarios for different SG ratings beyond what is on the SG Ratings wiki page. The overall goal is to be able to do most of the SG rating at a cursory level without having to have Dan present. Right now, Dan is obligated to be part of rating things because of the lack of options but it puts him in pretty much every security triage, whether he has the time or not.

The overall goal is to come up with a triage process for bugs that might be less definitive but leaves us without any single person being ultimately necessary to always attend.

Are the following examples still accurate? Have we changed these or added to them during the normal course of triaging? These are the ones from the wiki but I'm not sure they reflect current reality anymore.

Also, with the switch to the new keywords today (as Curtis expressed to me), Al suggested that we add a whiteboard tag to mark a rating that we think is provisional, which would make it easier for someone like Dan to look at a processed list and double-check the things that we were concerned about. Al suggested something like [sec-rating-provisional] or similar.

==sec-critical==

Run attacker code with local user privilege or install malicious  software, requiring no user interaction beyond normal browsing.  

Bugzilla keyword description:
"Exploitable vulnerabilities which can lead to the widespread compromise of many users."

Examples:
* Overflows resulting in native code execution 
* JavaScript injection into browser chrome 
* Launching of arbitrary local application with provided arguments 
* Filetype spoofing where executables can masquerade as benign content types 
* Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue 
* Any crash where random memory or NULL is executed (the top of the stack is not a function) 
* Any crash where random memory is accessed 
* Any bug where random memory is written to is critical 
* Any bug where random memory is read from and then used in a  subsequent memory or jump operation (offset, array, etc)  is critical 

==sec-high==

Obtain confidential data from other sites the user is visiting  or the local machine, or inject data or code into those sites, requiring  no more than normal browsing actions. Indefinite DoS of the user's  system, requiring OS reinstallation or extensive cleanup 

Bugzilla keyword description:
"Obtain confidential data from other sites the user is visiting or the local machine, or inject data or code into those sites, requiring no more than normal browsing actions. Exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users."

Examples:
* Cross-site Scripting (XSS) 
* 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 

==sec-moderate==

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). Indefinite application Denial of Service (DoS) via  corruption of state, requiring application re-installation or temporary  DoS of the user's system, requiring reboot.

Bugzilla keyword description:
"Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities."

Examples:
* Disclosure of OS username 
* Disclosure of browser cache salt 
* Disclosure of entire browsing history 
* Detection of arbitrary local files 
* Launching of arbitrary local application without arguments 
* Local storage of passwords in unencrypted form 
* Persistent DoS attacks that prevent the user from starting Firefox or another application in the future 

==sec-low==

Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. 

Bugzilla keyword description:
"Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls."

Examples:
* Detection of previous visit to a specific site 
* Identification of users by profiling browsing behavior. 
* Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages

==sec-other==

A category for bugs that we need to keep hidden (due to possible disclosure, etc) but that don't match any other ratings. This is used to keep these bugs from showing up as untriaged.

Bugzilla keyboard description:
"Bugs that may not be exploitable security issues but are kept confidential to protect sensitive information."

==sec-audit==

Bugzilla keyword description:
"Bug requires a code audit to investigate potential security problems."

==sec-incident==

Bugzilla keyword description:
"Issues resulting in an incident response or 'chemspill' actions by the security team."