A Complete Guide To The Common Vulnerability Scoring System
A Complete Guide To The Common Vulnerability Scoring System
Sasha Romanosky
Carnegie Mellon University
The Common Vulnerability Scoring System (CVSS) provides an open framework for
communicating the characteristics and impacts of IT vulnerabilities. CVSS consists of 3 groups:
Base, Temporal and Environmental. Each group produces a numeric score ranging from 0 to 10,
and a Vector, a compressed textual representation that reflects the values used to derive the
score. The Base group represents the intrinsic qualities of a vulnerability. The Temporal group
reflects the characteristics of a vulnerability that change over time. The Environmental group
represents the characteristics of a vulnerability that are unique to any user's environment. CVSS
enables IT managers, vulnerability bulletin providers, security vendors, application vendors and
researchers to all benefit by adopting this common language of scoring IT vulnerabilities.
1. Introduction
Currently, IT management must identify and assess vulnerabilities across many disparate
hardware and software platforms. They need to prioritize these vulnerabilities and remediate
those that pose the greatest risk. But when there are so many to fix, with each being scored
using different scales [2][3][4], how can IT managers convert this mountain of vulnerability data
into actionable information? The Common Vulnerability Scoring System (CVSS) is an open
framework that addresses this issue. It offers the following benefits:
Base: represents the intrinsic and fundamental characteristics of a vulnerability that are
constant over time and user environments. Base metrics are discussed in Section 2.1.
Temporal: represents the characteristics of a vulnerability that change over time but not
among user environments. Temporal metrics are discussed in Section 2.2.
Environmental: represents the characteristics of a vulnerability that are relevant and
unique to a particular user's environment. Environmental metrics are discussed in
Section 2.3.
The purpose of the CVSS base group is to define and communicate the fundamental
characteristics of a vulnerability. This objective approach to characterizing vulnerabilities
provides users with a clear and intuitive representation of a vulnerability. Users can then invoke
the temporal and environmental groups to provide contextual information that more
accurately reflects the risk to their unique environment. This allows them to make more
informed decisions when trying to mitigate risks posed by the vulnerabilities.
CVSS can also be described by what it is not. That is, it is none of the following:
A threat rating system such as those used by the US Department of Homeland Security,
and the Sans Internet Storm Center.[1] These services provide an advisory warning
system for threats to critical US and global IT networks, respectively.
A vulnerability database such as the National Vulnerability Database (NVD), Open
Source Vulnerability Database (OSVDB) or Bugtraq. These databases provide a rich
catalogue of known vulnerabilities and vulnerability details.
A vulnerability identification system such as the industry-standard Common
Vulnerabilities and Exposures (CVE) or a weakness dictionary such as the Common
Weakness Enumeration (CWE). These frameworks are meant to uniquely identify and
classify vulnerabilities according to the causes "as they are manifested in code, design,
or architecture." [2]
If desired, the base score can be refined by assigning values to the temporal and environmental
metrics. This is useful in order to provide additional context for a vulnerability by more
accurately reflecting the risk posed by the vulnerability to a user's environment. However, this
is not required. Depending on one's purpose, the base score and vector may be sufficient.
If a temporal score is needed, the temporal equation will combine the temporal metrics with
the base score to produce a temporal score ranging from 0 to 10. Similarly, if an environmental
score is needed, the environmental equation will combine the environmental metrics with the
temporal score to produce an environmental score ranging from 0 to 10. Base, temporal and
environmental equations are fully described in Section 3.2.
This metric reflects how the vulnerability is exploited. The possible values for this metric are
listed in Table 1. The more remote an attacker can be to attack a host, the greater the
vulnerability score.
Metric
Description
Value
A vulnerability exploitable with only local access requires the attacker to have
either physical access to the vulnerable system or a local (shell) account. Examples
Local (L)
of locally exploitable vulnerabilities are peripheral attacks such as Firewire/USB
DMA attacks, and local privilege escalations (e.g., sudo).
A vulnerability exploitable with adjacent network access requires the attacker to
Adjacent
have access to either the broadcast or collision domain of the vulnerable software.
Network
Examples of local networks include local IP subnet, Bluetooth, IEEE 802.11, and
(A)
local Ethernet segment.
A vulnerability exploitable with network access means the vulnerable software is
Network bound to the network stack and the attacker does not require local network access
(N) or local access. Such a vulnerability is often termed "remotely exploitable". An
example of a network attack is an RPC buffer overflow.
This metric measures the complexity of the attack required to exploit the vulnerability once an
attacker has gained access to the target system. For example, consider a buffer overflow in an
Internet service: once the target system is located, the attacker can launch an exploit at will.
Other vulnerabilities, however, may require additional steps in order to be exploited. For
example, a vulnerability in an email client is only exploited after the user downloads and opens
a tainted attachment. The possible values for this metric are listed in Table 2. The lower the
required complexity, the higher the vulnerability score.
Metric
Description
Value
Specialized access conditions exist. For example:
The access conditions are somewhat specialized; the following are examples:
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
Low (L)
server).
The affected configuration is default or ubiquitous.
The attack can be performed manually and requires little skill or additional
information gathering.
The race condition is a lazy one (i.e., it is technically a race but easily
winnable).
This metric measures the number of times an attacker must authenticate to a target in order to
exploit a vulnerability. This metric does not gauge the strength or complexity of the
authentication process, only that an attacker is required to provide credentials before an
exploit may occur. The possible values for this metric are listed in Table 3. The fewer
authentication instances that are required, the higher the vulnerability score.
Metric
Description
Value
Exploiting the vulnerability requires that the attacker authenticate two or more times,
Multiple even if the same credentials are used each time. An example is an attacker
(M) authenticating to an operating system in addition to providing credentials to access
an application hosted on that system.
The vulnerability requires an attacker to be logged into the system (such as at a
Single (S)
command line or via a desktop session or web interface).
None (N) Authentication is not required to exploit the vulnerability.
The metric should be applied based on the authentication the attacker requires before
launching an attack. For example, if a mail server is vulnerable to a command that can be issued
before a user authenticates, the metric should be scored as "None" because the attacker can
launch the exploit before credentials are required. If the vulnerable command is only available
after successful authentication, then the vulnerability should be scored as "Single" or
"Multiple," depending on how many instances of authentication must occur before issuing the
command.
Metric
Description
Value
None (N) There is no impact to the confidentiality of the system.
Partial (P) There is considerable informational disclosure. Access to some system files is
possible, but the attacker does not have control over what is obtained, or the scope
of the loss is constrained. An example is a vulnerability that divulges only certain
tables in a database.
Complete There is total information disclosure, resulting in all system files being revealed. The
(C) attacker is able to read all of the system's data (memory, files, etc.)
This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity
refers to the trustworthiness and guaranteed veracity of information. The possible values for
this metric are listed in Table 5. Increased integrity impact increases the vulnerability score.
Metric
Description
Value
None (N) There is no impact to the integrity of the system.
Modification of some system files or information is possible, but the attacker does
not have control over what can be modified, or the scope of what the attacker can
Partial (P) affect is limited. For example, system or application files may be overwritten or
modified, but either the attacker has no control over which files are affected or the
attacker can modify files within only a limited context or scope.
There is a total compromise of system integrity. There is a complete loss of system
Complete
protection, resulting in the entire system being compromised. The attacker is able to
(C)
modify any files on the target system.
Metric
Description
Value
None (N) There is no impact to the availability of the system.
There is reduced performance or interruptions in resource availability. An example is
Partial (P) a network-based flood attack that permits a limited number of successful
connections to an Internet service.
Complete There is a total shutdown of the affected resource. The attacker can render the
(C) resource completely unavailable.
This metric measures the current state of exploit techniques or code availability. Public
availability of easy-to-use exploit code increases the number of potential attackers by including
those who are unskilled, thereby increasing the severity of the vulnerability.
Initially, real-world exploitation may only be theoretical. Publication of proof of concept code,
functional exploit code, or sufficient technical details necessary to exploit the vulnerability may
follow. Furthermore, the exploit code available may progress from a proof-of-concept
demonstration to exploit code that is successful in exploiting the vulnerability consistently. In
severe cases, it may be delivered as the payload of a network-based worm or virus. The
possible values for this metric are listed in Table 7. The more easily a vulnerability can be
exploited, the higher the vulnerability score.
The remediation level of a vulnerability is an important factor for prioritization. The typical
vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim
remediation until an official patch or upgrade is issued. Each of these respective stages adjusts
the temporal score downwards, reflecting the decreasing urgency as remediation becomes
final. The possible values for this metric are listed in Table 8. The less official and permanent a
fix, the higher the vulnerability score is.
This metric measures the degree of confidence in the existence of the vulnerability and the
credibility of the known technical details. Sometimes, only the existence of vulnerabilities are
publicized, but without specific details. The vulnerability may later be corroborated and then
confirmed through acknowledgement by the author or vendor of the affected technology. The
urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This
metric also suggests the level of technical knowledge available to would-be attackers. The
possible values for this metric are listed in Table 9. The more a vulnerability is validated by the
vendor or other reputable sources, the higher the score.
This metric measures the potential for 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.
The possible values for this metric are listed in Table 10. Naturally, the greater the damage
potential, the higher the vulnerability score.
Clearly, each organization must determine for themselves the precise meaning of "slight,
moderate, significant, and catastrophic."
Metric
Description
Value
No target systems exist, or targets are so highly specialized that they only exist in a
None (N)
laboratory setting. Effectively 0% of the environment is at risk.
Targets exist inside the environment, but on a small scale. Between 1% - 25% of
Low (L)
the total environment is at risk.
Targets exist inside the environment, but on a medium scale. Between 26% - 75%
Medium (M)
of the total environment is at risk.
Targets exist inside the environment on a considerable scale. Between 76% - 100%
High (H)
of the total environment is considered at risk.
Not Defined Assigning this value to the metric will not influence the score. It is a signal to the
(ND) equation to skip this metric.
These metrics enable the analyst to customize the CVSS score depending on the importance of
the affected IT asset to a users organization, measured in terms of confidentiality, integrity, and
availability, That is, if an IT asset supports a business function for which availability is most
important, the analyst can assign a greater value to availability, relative to confidentiality and
integrity. Each security requirement has three possible values: low, medium, or high.
The full effect on the environmental score is determined by the corresponding base impact
metrics (please note that the base confidentiality, integrity and availability impact metrics,
themselves, are not changed). That is, these metrics modify the environmental score by
reweighting the (base) confidentiality, integrity, and availability impact metrics. For example,
the confidentiality impact (C) metric has increased weight if the confidentiality requirement
(CR) is high. Likewise, the confidentiality impact metric has decreased weight if the
confidentiality requirement is low. The confidentiality impact metric weighting is neutral if the
confidentiality requirement is medium. This same logic is applied to the integrity and
availability requirements.
Note that the confidentiality requirement will not affect the environmental score if the (base)
confidentiality impact is set to none. Also, increasing the confidentiality requirement from
medium to high will not change the environmental score when the (base) impact metrics are
set to complete. This is because the impact sub score (part of the base score that calculates
impact) is already at a maximum value of 10.
The possible values for the security requirements are listed in Table 12. For brevity, the same
table is used for all three metrics. The greater the security requirement, the higher the score
(remember that medium is considered the default). These metrics will modify the score as
much as plus or minus 2.5.
Metric
Description
Value
Loss of [confidentiality | integrity | availability] is likely to have only a limited
Low (L) adverse effect on the organization or individuals associated with the organization
(e.g., employees, customers).
Loss of [confidentiality | integrity | availability] is likely to have a serious adverse
Medium
effect on the organization or individuals associated with the organization (e.g.,
(M)
employees, customers).
Loss of [confidentiality | integrity | availability] is likely to have a catastrophic
High (H) adverse effect on the organization or individuals associated with the organization
(e.g., employees, customers).
Not
Assigning this value to the metric will not influence the score. It is a signal to the
Defined
equation to skip this metric.
(ND)
In many organizations, IT resources are labeled with criticality ratings based on network
location, business function, and potential for loss of revenue or life. For example, the U.S.
government assigns every unclassified IT asset to a grouping of assets called a System. Every
System must be assigned three "potential impact" ratings to show the potential impact on the
organization if the System is compromised according to three security objectives:
confidentiality, integrity, and availability. Thus, every unclassified IT asset in the U.S.
government has a potential impact rating of low, moderate, or high with respect to the security
objectives of confidentiality, integrity, and availability. This rating system is described within
Federal Information Processing Standards (FIPS) 199. CVSS follows this general model of FIPS
199, but does not require organizations to use any particular system for assigning the low,
medium, and high impact ratings.
2.4. Base, Temporal, Environmental Vectors
Each metric in the vector consists of the abbreviated metric name, followed by a ":" (colon),
then the abbreviated metric value. The vector lists these metrics in a predetermined order,
using the "/" (slash) character to separate the metrics. If a temporal or environmental metric is
not to be used, it is given a value of "ND" (not defined). The base, temporal, and environmental
vectors are shown below in Table 13.
For example, a vulnerability with base metric values of "Access Vector: Low, Access Complexity:
Medium, Authentication: None, Confidentiality Impact: None, Integrity Impact: Partial,
Availability Impact: Complete" would have the following base vector:
"AV:L/AC:M/Au:N/C:N/I:P/A:C."
3. Scoring
3.1. Guidelines
Below are guidelines that should help analysts when scoring vulnerabilities.
3.1.1. General
SCORING TIP #1: Vulnerability scoring should not take into account any interaction with other
vulnerabilities. That is, each vulnerability should be scored independently.
SCORING TIP #2: When scoring a vulnerability, consider the direct impact to the target host
only. For example, consider a cross-site scripting vulnerability: the impact to a user's system
could be much greater than the impact to the target host. However, this is an indirect impact.
Cross-site scripting vulnerabilities should be scored with no impact to confidentiality or
availability, and partial impact to integrity.
SCORING TIP #3: Many applications, such as Web servers, can be run with different privileges,
and scoring the impact involves making an assumption as to what privileges are used.
Therefore, vulnerabilities should be scored according to the privileges most commonly used.
This may not necessarily reflect security best practices, especially for client applications which
are often run with root-level privileges. When uncertain as to which privileges are most
common, scoring analysts should assume a default configuration.
SCORING TIP #4: When scoring the impact of a vulnerability that has multiple exploitation
methods (attack vectors), the analyst should choose the exploitation method that causes the
greatest impact, rather than the method which is most common, or easiest to perform. For
example, if functional exploit code exists for one platform but not another, then Exploitability
should be set to "Functional". If two separate variants of a product are in parallel development
(e.g. PHP 4.x and PHP 5.x), and a fix exists for one variant but not another, then the
Remediation Level should be set to "Unavailable".
SCORING TIP #5: When a vulnerability can be exploited both locally and from the network, the
"Network" value should be chosen. When a vulnerability can be exploited both locally and from
adjacent networks, but not from remote networks, the "Adjacent Network" value should be
chosen. When a vulnerability can be exploited from the adjacent network and remote
networks, the "Network" value should be chosen.
SCORING TIP #6: Many client applications and utilities have local vulnerabilities that can be
exploited remotely either through user-complicit actions or via automated processing. For
example, decompression utilities and virus scanners automatically scan incoming email
messages. Also, helper applications (office suites, image viewers, media players, etc.) are
exploited when malicious files are exchanged via e-mail or downloaded from web sites.
Therefore, analysts should score the Access Vector of these vulnerabilities as "Network".
3.1.2.2. Authentication
SCORING TIP #7: If the vulnerability exists in an authentication scheme itself (e.g., PAM,
Kerberos) or an anonymous service (e.g., public FTP server), the metric should be scored as
"None" because the attacker can exploit the vulnerability without supplying valid credentials.
Presence of a default user account may be considered as "Single" or "Multiple" Authentication
(as appropriate), but may have Exploitability of "High" if the credentials are publicized.
SCORING TIP #8: It is important to note that the Authentication metric is different from Access
Vector. Here, authentication requirements are considered once the system has already been
accessed. Specifically, for locally exploitable vulnerabilities, this metric should only be set to
"single" or "multiple" if authentication is needed beyond what is required to log into the
system. An example of a locally exploitable vulnerability that requires authentication is one
affecting a database engine listening on a Unix domain socket (or some other non-network
interface). If the user must authenticate as a valid database user in order to exploit the
vulnerability, then this metric should be set to "single."
SCORING TIP #9: Vulnerabilities that give root-level access should be scored with complete loss
of confidentiality, integrity, and availability, while vulnerabilities that give user-level access
should be scored with only partial loss of confidentiality, integrity, and availability. For example,
an integrity violation that allows an attacker to modify an operating system password file
should be scored with complete impact of confidentiality, integrity, and availability.
SCORING TIP #10: Vulnerabilities with a partial or complete loss of integrity can also cause an
impact to availability. For example, an attacker who is able to modify records can probably also
delete them.
3.2. Equations
Scoring equations and algorithms for the base, temporal and environmental metric groups are
described below. Further discussion of the origin and testing of these equations is available at
www.first.org/cvss.
The base equation is the foundation of CVSS scoring. The base equation (formula version 2.10)
is:
BaseScore = round_to_1_decimal(((0.6*Impact)+(0.4*Exploitability)-1.5)*f(Impact))
Impact = 10.41*(1-(1-ConfImpact)*(1-IntegImpact)*(1-AvailImpact))
If employed, the temporal equation will combine the temporal metrics with the base score to
produce a temporal score ranging from 0 to 10. Further, the temporal score will produce a
temporal score no higher than the base score, and no greater than 33% lower than the base
score. The temporal equation is:
TemporalScore = round_to_1_decimal(BaseScore*Exploitability
*RemediationLevel*ReportConfidence)
If employed, the environmental equation will combine the environmental metrics with the
temporal score to produce an environmental score ranging from 0 to 10. Further, this equation
will produce a score no higher than the temporal score. The environmental equation is:
EnvironmentalScore = round_to_1_decimal((AdjustedTemporal+
(10-AdjustedTemporal)*CollateralDamagePotential)*TargetDistribution)
AdjustedTemporal = TemporalScore recomputed with the BaseScores Impact sub-equation replaced with the
AdjustedImpact equation
AdjustedImpact = min(10,10.41*(1-(1-ConfImpact*ConfReq)*(1-IntegImpact*IntegReq)
*(1-AvailImpact*AvailReq)))
3.3. Examples
Below, we provide examples of how CVSS is used for three different vulnerabilities.
3.3.1. CVE-2002-0392
Since the vulnerability can be exploited remotely, the Access Vector is "Network". The Access
Complexity is "Low" because no additional circumstances need to exist for this exploit to be
successful; the attacker need only craft a proper exploit message to the Apache web listener.
No authentication is required to trigger the vulnerability (any Internet user can connect to the
web server), so the Authentication metric is "None".
Since the vulnerability can be exploited using multiple methods with different outcomes, scores
need to be generated for each method and the highest used.
If the vulnerability is exploited to execute arbitrary code with the permissions of the web
server, thereby altering web content and possibly viewing local user or configuration
information (including connection settings and passwords to back-end databases), the
Confidentiality and Integrity Impact metrics are set to "Partial". Together, these metrics result
in a base score of 6.4.
If the vulnerability is exploited to cause a denial of service, the Availability Impact is set to
"Complete". Together, the metrics produce a base score of 7.8. Since this is the highest possible
base score of the exploitation options, it is used as the base score.
Exploit code is known to exist and therefore Exploitability is set to "Functional". The Apache
foundation has released patches for this vulnerability (available to both 1.3 and 2.0) and so
Remediation Level is "Official-Fix". Naturally, report confidence is "Confirmed". These metrics
adjust the base score to give a temporal score of 6.4.
Assuming that availability is more important than usual for the targeted systems, and
depending on the values for Collateral Damage Potential and Target Distribution, the
environmental score could vary between 0.0 ("None", "None") and 9.2 ("High", "High"). The
results are summarized below.
----------------------------------------------------
BASE METRIC EVALUATION SCORE
----------------------------------------------------
Access Vector [Network] (1.00)
Access Complexity [Low] (0.71)
Authentication [None] (0.704)
Confidentiality Impact [None] (0.00)
Integrity Impact [None] (0.00)
Availability Impact [Complete] (0.66)
----------------------------------------------------
BASE FORMULA BASE SCORE
----------------------------------------------------
Impact = 10.41*(1-(1)*(1)*(0.34)) == 6.9
Exploitability = 20*0.71*0.704*1 == 10.0
f(Impact) = 1.176
BaseScore = (0.6*6.9 + 0.4*10.0 1.5)*1.176
== (7.8)
----------------------------------------------------
----------------------------------------------------
TEMPORAL METRIC EVALUATION SCORE
----------------------------------------------------
Exploitability [Functional] (0.95)
Remediation Level [Official-Fix] (0.87)
Report Confidence [Confirmed] (1.00)
----------------------------------------------------
TEMPORAL FORMULA TEMPORAL SCORE
----------------------------------------------------
round(7.8 * 0.95 * 0.87 * 1.00) == (6.4)
----------------------------------------------------
----------------------------------------------------
ENVIRONMENTAL METRIC EVALUATION SCORE
----------------------------------------------------
Collateral Damage Potential [None - High] {0 - 0.5}
Target Distribution [None - High] {0 - 1.0}
Confidentiality Req. [Medium] (1.0)
Integrity Req. [Medium] (1.0)
Availability Req. [High] (1.51)
----------------------------------------------------
ENVIRONMENTAL FORMULA ENVIRONMENTAL SCORE
----------------------------------------------------
AdjustedImpact = min(10,10.41*(1-(1-0*1)*(1-0*1)
*(1-0.66*1.51)) == (10.0)
AdjustedBase =((0.6*10)+(0.4*10.0)1.5)*1.176
== (10.0)
AdjustedTemporal == (10*0.95*0.87*1.0) == (8.3)
EnvScore = round((8.3+(10-8.3)*{0-0.5})*{0-1})
== (0.00 - 9.2)
----------------------------------------------------
3.3.2. CVE-2003-0818
This is a remotely exploitable vulnerability that does not require authentication, therefore the
Access Vector is "Network" and "Authentication" is "None". The Access Complexity is "Low"
because no additional access or specialized circumstances need to exist for the exploit to be
successful. Each of the Impact metrics is set to "Complete" because of the possibility of a
complete system compromise. Together, these metrics produce a maximum base score of 10.0.
Known exploits do exist for this vulnerability and so Exploitability is "Functional". In February
2004, Microsoft released patch MS04-007, making the Remediation Level "Official-Fix" and the
Report Confidence "Confirmed". These metrics adjust the base score to give a temporal score of
8.3.
Assuming that availability is less important than usual for the targeted systems, and depending
on the values for Collateral Damage Potential and Target Distribution, the environmental score
could vary between 0.0 ("None", "None") and 9.0 ("High", "High"). The results are summarized
below.
----------------------------------------------------
BASE METRIC EVALUATION SCORE
----------------------------------------------------
Access Vector [Network] (1.00)
Access Complexity [Low] (0.71)
Authentication [None] (0.704)
Confidentiality Impact [Complete] (0.66)
Integrity Impact [Complete] (0.66)
Availability Impact [Complete] (0.66)
----------------------------------------------------
FORMULA BASE SCORE
----------------------------------------------------
Impact = 10.41*(1-(0.34*0.34*0.34)) == 10.0
Exploitability = 20*0.71*0.704*1 == 10.0
f(Impact) = 1.176
BaseScore =((0.6*10.0)+(0.4*10.0)1.5)*1.176
== (10.0)
----------------------------------------------------
----------------------------------------------------
TEMPORAL METRIC EVALUATION SCORE
----------------------------------------------------
Exploitability [Functional] (0.95)
Remediation Level [Official-Fix] (0.87)
Report Confidence [Confirmed] (1.00)
----------------------------------------------------
FORMULA TEMPORAL SCORE
----------------------------------------------------
round(10.0 * 0.95 * 0.87 * 1.00) == (8.3)
----------------------------------------------------
----------------------------------------------------
ENVIRONMENTAL METRIC EVALUATION SCORE
----------------------------------------------------
Collateral Damage Potential [None - High] {0 - 0.5}
Target Distribution [None - High] {0 - 1.0}
Confidentiality Req. [Medium] (1.0)
Integrity Req. [Medium] (1.0)
Availability Req. [Low] (0.5)
----------------------------------------------------
FORMULA ENVIRONMENTAL SCORE
----------------------------------------------------
AdjustedImpact = 10.41*(1-(1-0.66*1)*(1-0.66*1)
*(1-0.66*0.5)) == 9.6
AdjustedBase =((0.6*9.6)+(0.4*10.0)1.5)*1.176
== (9.7)
AdjustedTemporal == (9.7*0.95*0.87*1.0) == (8.0)
EnvScore = round((8.0+(10-8.0)*{0-0.5})*{0-1})
== (0.00 - 9.0)
----------------------------------------------------
3.3.3. CVE-2003-0062
Since the vulnerability is exploitable only to a user locally logged into the system, the Access
Vector is "Local". The Access Complexity is "High" because this vulnerability is not exploitable at
the attacker's whim. There is an additional layer of complexity because the attacker must wait
for another user to run the virus scanning software. Authentication is set to "None" because
the attacker does not need to authenticate to any additional system. If an administrative user
were to run the virus scan, causing the buffer overflow, then a full system compromise would
be possible. Since the most harmful case must be considered, each of the three Impact metrics
is set to "Complete". Together, these metrics produce a base score of 6.2.
Partial exploit code has been released, so the Exploitability metric is set to "Proof-Of-Concept".
Eset has released updated software, giving a Remediation Level of "Official-Fix" and Report
Confidence of "Confirmed". These three metrics adjust the base score to give a temporal score
of 4.9.
Assuming that confidentiality, integrity, and availability are roughly equally important for the
targeted systems, and depending on the values for Collateral Damage Potential and Target
Distribution, the environmental score could vary between 0.0 ("None", "None") and 7.5 ("High",
"High"). The results are summarized below.
----------------------------------------------------
BASE METRIC EVALUATION SCORE
----------------------------------------------------
Access Vector [Local] (0.395)
Access Complexity [High] (0.35)
Authentication [None] (0.704)
Confidentiality Impact [Complete] (0.66)
Integrity Impact [Complete] (0.66)
Availability Impact [Complete] (0.66)
----------------------------------------------------
FORMULA BASE SCORE
----------------------------------------------------
Impact = 10.41*(1-(0.34*0.34*0.34)) == 10.0
Exploitability = 20*0.35*0.704*0.395 == 1.9
f(Impact) = 1.176
BaseScore =((0.6*10)+(0.4*1.9)1.5)*1.176
== (6.2)
----------------------------------------------------
----------------------------------------------------
TEMPORAL METRIC EVALUATION SCORE
----------------------------------------------------
Exploitability [Proof-Of-Concept](0.90)
Remediation Level [Official-Fix] (0.87)
Report Confidence [Confirmed] (1.00)
----------------------------------------------------
FORMULA TEMPORAL SCORE
----------------------------------------------------
round(6.2 * 0.90 * 0.87 * 1.00) == (4.9)
----------------------------------------------------
----------------------------------------------------
ENVIRONMENTAL METRIC EVALUATION SCORE
----------------------------------------------------
Collateral Damage Potential [None - High] {0 - 0.5}
Target Distribution [None - High] {0 - 1.0}
Confidentiality Req. [Medium] (1.0)
Integrity Req. [Medium] (1.0)
Availability Req. [Medium] (1.0)
----------------------------------------------------
FORMULA ENVIRONMENTAL SCORE
----------------------------------------------------
AdjustedTemporal == 4.9
EnvScore = round((4.9+(10-4.9)*{0-0.5})*{0-1})
== (0.00 - 7.5)
----------------------------------------------------
4. Additional Resources
Below, we present a list of resources that may be useful to anyone implementing CVSS.
Vulnerability bulletins are helpful when searching for detailed information about a particular
vulnerability. CVSS calculators are helpful when trying to compute your own base, temporal or
environmental scores.
Vulnerability bulletins:
CVSS Calculators
The NIST CVSSv2 calculator can be found at
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2
The Information-Technology Promotion Agency of Japan: http://jvnrss.ise.chuo-
u.ac.jp/jtg/cvss/en/CVSSv2.html
5. Final Remarks
The authors recognize that many other metrics could have been included in CVSS. We also
realize that no one scoring system will fit everyone's needs perfectly. The particular metrics
used in CVSS were identified as the best compromise between completeness, ease-of-use and
accuracy. They represent the cumulative experience of the CVSS Special Interest Group
members as well as extensive testing of real-world vulnerabilities in end-user environments. As
CVSS matures, these metrics may expand or adjust, making the scoring even more accurate,
flexible and representative of modern vulnerabilities and their risks.
6. References
[1]. Mike Schiffman, Gerhard Eschelbeck, David Ahmad, Andrew Wright, Sasha Romanosky,
"CVSS: A Common Vulnerability Scoring System", National Infrastructure Advisory Council
(NIAC), 2004.
[2]. Microsoft Corporation. Microsoft Security Response Center Security Bulletin Severity Rating
System. November 2002 [cited 16 March 2007]. Available from URL:
http://www.microsoft.com/technet/security/bulletin/rating.mspx.
[3]. United States Computer Emergency Readiness Team (US-CERT). US-CERT Vulnerability Note
Field Descriptions. 2006 [cited 16 March 2007]. Available from URL:
http://www.kb.cert.org/vuls/html/fieldhelp.
[4]. SANS Institute. SANS Critical Vulnerability Analysis Archive. Undated [cited 16 March 2007].
Available from URL: http://www.sans.org/newsletters/cva/.