3 Things That Improved With CVSSv3
A key pillar of any well defined software security program is an effective vulnerability management system. An integral part of such a system is a uniform scoring function so vulnerabilities can be compared and prioritized consistently. An information security team's worst nightmare is to have more than one vulnerability scoring system. Imagine the dread of prioritising remediation efforts or running KPIs across various vulnerability sources that use different scoring systems!
For many years now CVSS has been the de facto standard for vulnerability risk scoring. It has been heavily criticised by some in the security community and personally to me it sometimes feels a bit off when scoring risk for vulnerabilities discovered during security testing engagements, due to the fact that the score does not reflect the true impact of a vulnerability. Version 3 has been released in June last year and it promises to address various issues that have been heavily debated in the past.
A classic example
Let’s take a look at a classic example where v2 has failed us in the past. A typical path disclosure issue reveals the physical path of a file on the file system. For an attacker this type of vulnerability is not particularly useful and it only comes into play when it can be chained with another vulnerability. For instance, a file upload that allows to create dynamic code on a web server. In this case the information from a path disclosure could be leveraged to upload the dynamic code into an executable directory that would otherwise be unknown to the attacker. A vulnerability like that scores 5.0 base score in v2 (AV:N/AC:L/Au:N/C:P/I:N/A:N) which makes it a medium risk vulnerability. The score feels fairly high especially when other types of vulnerabilities of greater real world impact are compared against it.
A path traversal vulnerability is a totally different beast compared to a path disclosure vulnerability. Often it allows full read access to the file system with the rights of the application server running on the system. This probably includes large segments of user and application data, configuration files, home directories and so forth - a lot of things an attacker can leverage to launch further attacks. Now here comes the unpleasant surprise: A path traversal vulnerability gets the same base score 5.0 with v2 as the path disclosure vulnerability! Setting the confidentiality impact to "high" for the path traversal issue is really a stretch, I would consider this if the web server runs as root and every file on the system can be read. So the score for the two vulnerabilities stays the same and they both are ranked in the medium risk category.
Besides the slightly uncomfortable feeling of conveying such a misleading picture to a client, this creates a bigger issue for the remediation phase. An effective vulnerability management dictates to prioritise remediation efforts and address higher risk vulnerabilities first. In this case both vulnerabilities would have the exact same v2 score and therefore have the same priority for developers to be fixed.
A more realistic picture
For the path disclosure vulnerability rated under v3 there are no dramatic changes. It scores a base value of 5.3, even slightly higher than under v2. The dynamic has not changed much in v3 for this type of vulnerability. Also the environmental metric does not provide legitimate means to get this down to low risk in most cases. It gets more interesting with the path traversal vulnerability. For v2 Confidentiality, Integrity and Availability is rated either as none, partial or complete and it reflects the portion or percentage of the host system that has been impacted. In v3 this changes to the overall degree of impact to the component (or application) caused by the attack.
If the path traversal vulnerability allows an attacker to systematically read files from the system and therefore leads to a full compromise of the component or other serious impact such as retrieving admin or root credentials then the vulnerability can be rated 7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) which is classified as high risk vulnerability. A prominent example for a similar issue is the heart bleed vulnerability. For v2 this was rated as 5.0, for v3 this becomes 7.5 which just gives it a more real world vulnerability score.
A big step forward
How the change with v3 affects you depends a bit on what type of vulnerabilities you score on a day to day basis. From my point of view, the three most important changes with v3 are the following:
Host Platform / Component: This is probably the biggest change in v3 as it impacts the metric calculation for Confidentially, Integrity and Availability for the base score. As discussed in the example above full control or the highest privileges on the host system are not always the main objective of an attacker. Considering a component (or application) as fully compromised does provide a more accurate insight of the severity of a vulnerability.
Access Complexity (AC) / User Interaction (UI): AC included elements of UI in v2. This has been separated into two seperate metrics in v3, which makes it easier to score. The two do not always correlate in the same way.
Authentication (Au) / Privileges Required (PR): Au in v2 has three values None, Single and Multiple. This makes sense for applications that have a regular login and then require 2FA to access additional functionality. A lot of retail banking systems work like that nowadays. The problem with Au is that it does not capture the level of authorisation required. If a vulnerability can only be exploited as an administrator, it scores the same value in v2 as if it can be executed as standard user. PR solves this issue and it replaces Au in v3.
After using CVSS v2 for many years and considering that I have used v3 only for a few weeks I am still cautious to give my final judgment. Having said that v3 feels a lot more real world in cases where the v2 score is just not accurate. Apart the above listed changes, there are other interesting additions that are worth looking into, for example vulnerability chaining or the new Scope metric . A full list of changes can be found here.