Proposal #0 Additional access complexity granularity to base scoring

Release Date: 01/03/06
Status: Approved by CVSS SIG

Description:

Case to add additional granularity into AccessComplexity. We would change Add an additional "medium" field to help better describe the complexity needed to use a particular exploit.

Formula change

Case AccessComplexityCurrentWould change to
High 0.8 0.6
Medium — 0.8
Low 1.0 1.0

Documentation change

Current
High: Specialized access conditions exist; for example: the system is exploitable during specific windows of time (a race condition), the system is exploitable under specific circumstances (nondefault configurations), or the system is exploitable with victim interaction (vulnerability exploitable only if user opens e-mail)
Low: Specialized access conditions or extenuating circumstances do not exist; the system is always exploitable.
Proposed change
High: in MOST configs, the attacking party must already have high privileges; or, must control or spoof additional systems besides the attacking system (e.g. DNS); or, the attack can only be opportunistic, i.e. the attacker can not directly trigger the vulnerability; depends on social engineering methods that would be easily detected by knowledgeable people; or, the affected configuration is deemed to be very rare in practice; or, the race condition window is very narrow; or, depends on the presence of other vulnerabilities.
Medium: the attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted; there is a requirement for some information gathering before a successful attack can be launched; the affected functionality is not always used; or requires a small amount of social engineering that might occasionally fool cautious users (e.g. phishing attacks that modify the status bar to show a false link, having to be on someone's "buddy" list before sending an IM exploit).
Low: the affected product typically requires access to a wide range of systems and users, possibly anonymous and untrusted (e.g. Internet-facing web or mail server); the affected configuration is default or ubiquitous; the attack can be performed manually in one or two steps that require little skill or additional information gathering; the "race condition" is a lazy one, i.e. it is technically a race but easily winnable (as is the case with many symlink vulns).

Proposal #1

Release Date: 3/31/06
Status: Approved by CVSS SIG

Move the “impact bias” metric from the base scoring to the environmental scoring. In its new form within the environmental section, it would enable end users to declare which CIA attribute is most important to them in the context of a particular vulnerability.

Rational:

  • Which CIA metric is of most importance usually depends on the end user environment and their use of the software. For example, encryption software is suggested by CVSS v1.0 as a good candidate for a ‘confidentiality bias’. However, some organizations may prefer an ‘integrity bias’ if the integrity of the data being passed is more important than the confidentiality. Just because you're encrypting data doesn't mean that you don't care more about integrity (or even availability for that matter). It all depends on the type of data being transmitted and thus this metric fits better within the environmental scoring.
  • It is difficult to accurately determine this metric for the vast majority of software packages and thus it unnecessarily complicates the standard.
  • It is difficult to get analysts to consistently assign this metric and thus it promotes score inconsistency between organizations.

See section 7.5 of the NIST CVSS paper for more discussion of this proposal and for details on how it affected NIST’s overall scoring efforts.


Proposal #2

Release Date: 4/4/06
Status: Approved by CVSS SIG

Explicitly add to the CVSS standard that vulnerabilities that give root level access should be CIA of all ‘complete’ and vulnerabilities that give user level access to the OS or general access to an application should be CIA of ‘partial’. Make it clear in the standard that we are not just rating what access the vulnerability directly gives the attacker but what access it also indirectly gives the attacker. Thus an integrity violation that allows one to modify an OS password file would be labeled CIA of all ‘complete’. Also, we should mention that following this property means that in most cases integrity violations would enable one to cause availability problems and thus setting Integrity to ‘partial’ should usually imply a setting of ‘partial’ or ‘complete’ for availability.

The documentation should make clear that the indirect benefits should not take into account any interaction with other vulnerabilities that are simultaneously present.

Example:

a PHP application, by design, allows a special user to upload files. However, due to a vulnerability (issue 1), it allows the user to upload files with the .php extension, which are then executed from the web server. A separate issue 2 in the application allows an unauthenticated attacker to change their userID to arbitrary user IDs by means of a cookie. Due to the combination of these 2 issues, a remote attacker could execute arbitrary PHP code; but issue 1 alone requires authentication and special privileges, and issue 2 alone does not allow arbitrary code.

Rational:

This is commonly done by all who do large amounts of CVSS scoring but since it isn’t in the standard, it causes confusion for newcomers and possibly causes unnecessary criticism of the standard by those not in the community.


Proposal #3: Rewording of Access Complexity

Release Date: 4/4/06
Status: Approved by CVSS SIG

Reword the access complexity definition to make it clear that the metric is dealing with how easy it is to execute an attack once exploit code exists as opposed to measuring how hard it is to write exploit code.

Rational:

  • It is difficult for analysts to determine how hard it is to write exploit code and thus this metric could be set unreliably. For example, the current standard implies that all race conditions result in attacks that are difficult to launch but this is not always the case.
  • From the NIST CVSS paper: “Measuring the difficulty of writing exploit code within this metric is problematic when used in conjunction with CVSS temporal scoring. In calculating the CVSS base score, setting access complexity from “Low” to “High” drops a score by 20%. When calculating the temporal score, there is a metric called Exploitability which has four options: unproven an exploit exists, proof of concept code available, functional exploit available, and exploit incorporated into major worm or virus. Once a functional exploit is available, it no longer matters whether or not it was difficult to write the exploit. Thus, in the temporal scoring one should ideally ignore or undo the effects of the exploit code writing element of the access complexity metric whenever a proof of concept exploit is publicly available. Instead, the temporal exploitability metric can only further reduce the CVSS score due to the way the temporal score equation is constructed. This means that a vulnerability exploited by a major worm that was difficult to write will have a lower score in the CVSS temporal scoring than a vulnerability exploited by a major worm that was easy to write. However, when a major worm is released, the impact on computer systems has nothing to do with how much effort it took the virus writer to create the worm.“

Proposal #5: Additional Granularity for Access Vector

Release Date: 4/12/06
Status: Approved by CVSS SIG

Add a new option to the access vector metric for vulnerabilities that are accessible only over a local network and rename existing metrics appropriately. The new option is called “Local network accessible” (sometimes referred to as “adjacent” in the CVSS SIG email list discussions).

A vulnerability that is adjacently exploitable will have a lower score than a remotely exploitable vulnerability, and a higher score than a locally exploitable vulnerability.

Revised Access Vector Metric definitions:

  • Requires local access:
    The attacker must have physical access to the hardware the vulnerable software is running on, or a local shell account on the machine. The vulnerable software does not accept packets from the network stack. Examples of these would include peripherals attacks such as Firewire/USB DMA attacks, as well as local privilege escalations such as sudo privilege escalation.
  • Local Network accessible:
    The attacker must have access to the broadcast or collision domain that the vulnerable software is running on, or physical proximity to the hardware the vulnerable software is running on. Examples of local networks include: local IP subnet, Bluetooth, 802.11, and local Ethernet segment.
  • Network accessible
    The vulnerable software is bound to the network stack, and the attacker does not require local network access. An example of a network accessible attack is a RPC buffer overflow.

Proposal #6: Modification to Collateral Damage Potential

Release Date: 8/24/06
Status: Approved by CVSS SIG

1.3.1 Collateral Damage Potential

This metric measures the potential for a loss of life or physical assets through damage or theft of property or equipment. The metric may also measure economic loss of productivity or revenue.

1.3.1.1 Collateral Damage Potential Scoring Evaluation
None: There is no potential for loss of life, physical asset, productivity or revenue.
Low: A successful exploit of this vulnerability may result in light physical or property damage. Or, there may be slight loss of revenue or productivity to the organization.
Low-Medium:A successful exploit of this vulnerability may result in moderate physical or property damage. Or, there may be moderate loss of revenue or productivity to the organization.
Medium-High: A successful exploit of this vulnerability may result in significant physical or property damage or loss. Or, there may be significant loss of productivity or revenue.
High: A successful exploit of this vulnerability may result in catastrophic physical or property damage and loss. The range of effect may be over a wide area. Or, there may be catastrophic loss of productivity or revenue.

Proposal #7: Modification of Access Vector and Authentication Metrics

Release Date: 4/25/06
Status: Approved by CVSS SIG

Authentication Metric:

  • Requires no authentication
  • Requires a single instance of authentication
  • Requires multiple instances of authentication

Note:

the authentication metric measures what level of authentication/authorization is needed prior to launching the attack. The exact type of authentication is not being measured (e.g., we don't care for this metric whether or not an application authenticates using OS credentials or its own private scheme).

A single instance of authentication involves one requirement for an attacker to prove their identity. This metric does not gauge the strength or diversity of the authentication step (password and two-factor authentication are both a single instance of authentication), only that an attacker is asked to prove identity before an exploit may occur. Vulnerabilities that require an attacker to be logged in to a system (such as at a command-line or via a desktop session or web interface) represent a single instance of authentication.

Multiple instances of authentication are, therefore, two or more requirements for an attacker to prove identity. If an attacker must pass more than one request for authentication, such as authenticating to an operating system login as well as provide credentials to access an application hosted on that system, then multiple instances of authentication have been required. Again, note that the strength or diversity of authentication is not measured -- even if the credentials are identical for each instance of authentication, or if the second set of credentials is commonly "saved" (such as in an e-mail client).

Because authentication instances are measured as those required before launching an attack, the metric should be applied at the earliest stage from which an attacker can exploit the vulnerability. For example, if a mail server offers commands pre- and post- authentication that are vulnerable, the metric should score as No Authentication, because the attacker can launch the exploit before credentials are required; if the vulnerable commands are only available post-authentication, then it should be scored as a Single Instance. Also, if the vulnerability exists in an authentication scheme itself (e.g. PAM; default user account) or anonymous service (e.g. public FTP server), it may be necessary to score as No Authentication if the attacker can exploit the issue without supplying credentials.

Proposal #8: Direct and Indirect Impact of Exploitation

Release Date: 6/16/06
Status: Approved by CVSS SIG

Our multi-organization scoring comparison effort has revealed that the scoring of vulnerabilities that potentially have an impact on secondary hosts that access exploited servers, such as cross site scripting (XSS) vulnerabilities, is the cause of a large source of CVSS scoring discrepancies between multiple IT security organizations. For example, some analysts score XSS vulnerabilities with respect to the direct impact on the service, and some score them with respect to the indirect impact on an end user of the service.

In order to make scoring consistent and to focus scoring on the software that is directly vulnerable, the CVSS documentation should be updated to reflect that vulnerabilities should always be scored with respect to the impact on the vulnerable service. For the majority of cases CIA will be scored Confidentiality None, Integrity Partial, and Availability None.

Proposal #9: Assumptions for Application Privileges

Release Date: 8/24/06
Status: Approved by CVSS SIG

Our multi-organization scoring comparison effort has revealed that a major source of scoring discrepancies is different assumptions made by analysts as to the privileges under which various applications, such as Web servers and Web browsers, are run. For example, the scores for exploiting a Web server will be quite different if the Web server is assumed to run with root-level or user-level privileges.

To make scoring more consistent, the CVSS documentation should be updated to indicate that vulnerabilities should be scored based on the privileges that are most often used (sometimes referred to as “most probably”) for the application. This does not necessarily reflect the best practice for the application, especially for client applications, which are often run with root-level privileges. If it is not clear what privileges are most often used for an application, analysts should assume the default configuration.

Proposal #10: Handling Multiple Exploitation Methods

Release Date: 8/24/06
Status: Approved by CVSS SIG

Our multi-organization scoring comparison effort has revealed that some scoring discrepancies are due to analysts taking different approaches to handling cases where there is more than one way to exploit a particular vulnerability. For example, a vulnerability could be exploited using a low-complexity method to gain user-level access, and exploited using a high-complexity method to gain root access.

To make scoring more consistent, the CVSS documentation should be updated to indicate that analysts should generate a score for each approach to exploitation and then assign the vulnerability the highest of the scores. If the highest score is shared by multiple approaches, then analysts should compare those approaches and select the one that is most likely to be used.

Current text
The authors recognize that many other metrics could be included in CVSS. They also realize that no one scoring system will fit everyone's need perfectly. The particular constituent metrics used in CVSS were identified as the best compromise between completeness, ease-of-use and accuracy. They represent the cumulative experience of the authors as well as extensive testing of real-world vulnerabilities in end-user environments.
Proposed text
The authors recognize that many other metrics could be included in CVSS. They also realize that no one scoring system will fit everyone's need perfectly. The particular constituent metrics used in CVSS were identified as the best compromise between completeness, ease-of-use and accuracy. They represent the cumulative experience of the authors as well as extensive testing of real-world vulnerabilities in end-user environments. It is important to note that CVSS scoring on the impact of a vulnerability that has multiple exploitation methods the scorer chooses the exploit that has the most impact - the scorer should not choose the most like or easiest to exploit but go with the "worst case scenario" for given exploit.