The Common Vulnerability Scoring System Version 4.0 (CVSS v4.0) was released on 1 November 2023. The predecessor version CVSS v3.0 was introduced in March 2016 and has since been considered the standard for scoring the severity of vulnerabilities. In the article CVSSV3 as a Risk Metric we analysed version 3. The CVSS v4.0 Specification and the CVSS v4.0 calculator have been published on the website of the Forum of Incident Response and Security Teams (FIRST). This article shows the changes to version 3.1, discusses the changes to the rating of the base metric and the challenge of creating an accurate rating for a vulnerability.

Changes to CVSS v3.1

The Attack Requirements (AT) base metric has been introduced and the User Interaction (UI) metric was split into Passive (P) and Active (A) to classify a vulnerability’s base score more accurately. The Scope (S) metric has been replaced by splitting the impact metric into Vulnerable System (VC, VI, VA) and Subsequent System (SC, SI, SA). The implications for the base score are described in the following chapter.

The Temporal metric group has been renamed Threat and simplified. It now contains only Exploit Maturity (E), which describes the probability that the vulnerability will be exploited. This can be Attacked (A), Proof-of-Concept (P) or Unreported (U). This information is referred to by FIRST as Threat Intelligence and the metric should be regularly updated.

With the removal of the Remediation Level (RL) metric, information about whether a patch or workaround is available is lost. This is essential information for vulnerability management and will not be adequately replaced.

The purpose of the new Supplemental metric group is to allow organisations to define additional information about a vulnerability that is useful for risk analysis. The metric group is optional and does not impact the CVSS score. The metrics allow organisations to answer the following questions about the vulnerability:

• Safety: Does this vulnerability affect the safety of the organisation?
• Automatable: Can the vulnerability be exploited automatically?
• Recovery: After an attack, can resources be restored?
• Value Density: What resources will an attacker control after exploiting the vulnerability?
• Vulnerability Response Effort: How much effort is required for the first response?
• Provider Urgency: What is the severity of the vulnerability as assessed by the vendor?

Organisations can use the Environmental metric group to modify the base metric of a vulnerability to the specific properties of their own environment. This allows them to consider measures that have already been implemented and that have an impact on the exploitation of a vulnerability. For example, if the service is running in an isolated network, the Attack Vector can be reduced from Network to Adjacent. In this group of metrics, the creation of the Safety value for Integrity (MSI) and Availability (MSA) brings a stronger focus on Operational Technology (OT), Industrial Control Systems (ICS) and Safety in general.

Base Metric

The base metric rating assumes that the attacker has detailed knowledge of the vulnerability of the target system. This includes the baseline configuration and standard defences such as a host firewall or rate limiting. If specific defences have been implemented, such as an allow list, these should be accounted for in the Environment metric group and have no impact on the base metric.

Refined Exploitability Metric Classification

The previous definition of Attack Complexity (AC) has been changed by the creation of Attack Requirements (AT). AC now measures the hurdles that an attacker must overcome to exploit the vulnerability. These include, for example, the Address Space Layout Randomisation (ASLR) and Data Execution Prevention (DEP) techniques. Both techniques make it more difficult to develop exploits. Another example of AC is a secret that an attacker must know, like a secret key to break a crypto channel.

The Attack Requirements (AT) describe the necessary prerequisites to enable an attack on a vulnerable system. The difference with AC is that these conditions do not explicitly exist to prevent such an attack but are a natural consequence of the operation of the system. Examples include the need for a Machine-in-the-Middle (MitM) attack or the requirement for winning a race condition to successfully exploit an exploit.

However, penetration tester Konstantin describes in his article on the CVSS v4.0 Public Preview that the distinction between AC and AT is not always so clear. His example shows a vulnerable application running in a container. In principle, containers can be seen as a countermeasure against an attack, as the container separates the host system from the service. Containers are also a useful feature for scalability of applications, so the use of a container is a natural consequence. There is room for interpretation here, which can only be answered by the application developer in the specific case.

For the User Interaction (UI) metric, the introduction of the values Passive (P) and Active (A) simplifies the distinction. If a web application has a Stored XSS vulnerability, it is sufficient for the user to use the application normally for the JavaScript code to be executed in their browser. However, if it is a Reflected XSS vulnerability, the user must actively click on a crafted link for the malicious code to be executed.

The difference between Active and Passive of an XSS vulnerability is 0.2 points, the CVSS vector string for a Stored XSS vulnerability (Score 5.1) is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N and for the Reflected XSS vulnerability (Score 5.3) CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.

Extended Definition of Impact

The Scope metric has been replaced by a division of the impact scope into Vulnerable System (VC, VI, VA) and Subsequent System (SC, SI, SA). The impact of the vulnerability on surrounding systems is now also divided into Confidentiality, Integrity, and Availability, resulting in an extension of the base vector string. A vulnerable system is defined in the specification as follows:

Formally, a system of interest for scoring a vulnerability is defined as the set of computing logic that executes in an environment with a coherent function and set of security policies. The vulnerability exists in one or more components of such a system. A technology product or a solution that serves a purpose or function from a consumer’s perspective is considered a system (e.g., a server, workstation, containerized service, etc.).

If a system provides its functionality exclusively to another system, or if it was developed only for use by another system, then those two systems are included in the scope together. If the impact of a vulnerability extends beyond the defined system, this may be reflected in the Subsequent System metrics.

This vague definition of the system leaves room for interpretation. For example, in FIRST’s Examples it can be concluded that in the case of a vulnerability in a virtual machine (guest), such as CVE-2023-21989, the hypervisor (host) is considered to be a Subsequent System because the hypervisor also provides other virtual machines. In the examples for OpenSSL Heartbleed or log4shell, the entire system/device (web server and operating system) is included in the scope of the Vulnerable System. However, it would also be possible to set the boundary at the web server component and consider the underlying operating system as a Subsequent System. The classification of the Spring4shell vulnerability notes that other systems may be affected depending on the use of Spring, but that this should be considered in the Environmental metrics.

In the Eyes of the Beholder

The complexity of classifying a vulnerability is increased by CVSS v4.0, and the effort required to define an accurate classification increases. In addition, the classification of a vulnerability is more than ever in the eyes of the beholder. From the perspective of a security researcher and discoverer of a vulnerability, the highest possible impact should be assumed, for example a remote code execution (RCE) vulnerability is executed with the highest privileges and affects the entire system, resulting in a high CVSS score. Now, if this vulnerable component is discovered in a penetration test and the vulnerability is exploited, it is up to the penetration tester’s judgement whether or not to reclassify the impact. For example, if the code is executed on the system by a non-privileged service account, the impact is lower and should be remediated according to scope. Alternatively, the Environmental metric is additionally used for the penetration test to avoid discussions about why the rating is X in a vulnerability database and Y in the report.

The client, on the other hand, runs the system in a compartmentalised container, so the impact is further limited. Based on the CVSS specification, the customer can and should take this into account in the Environmental metric. Depending on the approach, there are now two corrected metrics, or the Environmental metric can be further refined by the customer.

Conclusion

The CVSS score provides an input to the risk assessment of a vulnerability with the severity of a vulnerability. When the CVSS score is obtained from a vulnerability database, there are known unknowns, such as what was used as the scope of the vulnerable system. To achieve an accurate rating, the score should be re-evaluated by the organisation depending on its environment. The separation of impacts introduced in version 4 will therefore lead to room for interpretation and different results. Without reassessment, work will continue with inaccurate information, which is the opposite of the purpose of such a score.

In order to benefit from the changes to the base score in CVSS v4.0, a reasonable amount of effort and reassessment must be made by subject matter experts who know the target environment and are familiar with the complexity of the rating. Otherwise, inaccurate information will be used, which is not an improvement over the status quo of CVSS v3.1.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://infosec.exchange/@kpwn
• https://kpwn.de/2023/08/cvss-v4.0-public-preview/#deployment-consequence-or-security-measure
• https://vuldb.com/?id.12819
• https://vuldb.com/?id.187925
• https://vuldb.com/?id.196076
• https://vuldb.com/?id.226737
• https://www.first.org/
• https://www.first.org/cvss/calculator/4.0
• https://www.first.org/cvss/v4-0/
• https://www.first.org/cvss/v4.0/examples
• https://www.first.org/cvss/v4.0/specification-document