Does CVSS 4.0 solve the exploitability problem?
The newest version of the vulnerability scoring system CVSS 4.0 is here! After a lengthy gap between version 3 (released in 2015), as of November 2023 version 4.0 is officially live. Building iteratively on version 3 there are a few differences that in theory should improve how we score, perceive and categorize vulnerabilities.
What was wrong with version 3.0?
Version 3.0 and CVSS in general, while being quite good at measuring the ”impact” of a vulnerability, wasn’t very good at scoring its “exploitability”. Exploitability conveys the likelihood of a vulnerability being exploited, after considering things such as interactions with end users, the skillset and capabilities of the threat actor, and the setup of the system in question.
Other criticisms of CVSS 3.0 were just as valid. Due to its focus on cyber threats, physical security risks didn’t fit well into the CVSS framework, nor did it fit well with complex interconnected systems with varied technology stacks or supply chains.
Add to this many of the parameters integrated into CVSS were always interpreted subjectively (different analysts come up with different scores) and it’s clear why CVSS was crying out for change.
What has changed?
Attack complexity – in version 3.0, the attack complexity parameter was binary, set to two options: high or low – nothing in between – and was open to completely subjective interpretation.
In version 4.0 this has been split into two parameters: attack complexity and attack requirements.
While the attack complexity parameter sadly hasn’t changed, attack requirements introduces the prerequisite deployment and execution conditions that need to be in place for the attack to succeed – for example: a specific configuration setting of a web server, presence of a specific code dependency, etc.
This differs from attack complexity, which has more to do with the security controls that must be overcome (e.g., ASLR for buffer overflows, WAFs, etc.) for the attack to succeed.
This is a welcome change since it gives more depth into requirements for the attack to succeed both on the defender and attacker side.
User interaction – In version 3.0, this was also binary condition: yes or no. For attacks involving any kind of user interactions this misrepresented what was required for the attack to succeed. For example, a user receiving a phishing e-mail with a URL to force him to visit a malicious site is a singular action, but a user having to download then open an attachment is more than one action – but both are treated the same way in version 3.0.
In version 4.0, this is split into three parameters: none, passive and active. Passive refers to interactions that don’t require the user to actively subvert security mechanisms – for example, a user visiting a website that has a stored cross-site scripting (XSS) is a passive interaction.
Active involves interaction from the user to dismiss/interact with pop-up prompts, such as what might be experienced when placing or download a file to their workstation with the associated pop-ups and prompts. This is a welcome addition, since version 3.0 had an “all or nothing” approach: if you required a user to interact 4 or 5 times it was treated the same way as a user requiring a single click of a URL.
There are other minor changes to other parameters and wording to streamline scoring, but these are the primary ones.
CVSS 4.0 in practice
Let’s run through a couple of examples to see if CVSS 4.0 changes anything.
Under CVSS3, a recent Avo (open-source ruby on rails admin panel creation framework) XSS vulnerability (CVE-2023-34103) gets a score of 5.4 (medium). Version 4.0 reduces it to 4.8 – a slight drop, but still a medium, mainly down to the user interaction parameter.
What about something more serious, like a flaw leading to remote code execution (RCE)?
CVE-2023-22523, a RCE in Atlassian’s Asset Discovery agent, gets a score of 8.8 (High) under CVSS3. As this vulnerability requires a specific configuration/agent setup, this drops to 7.8 (High) under version 4.0.
With both, these are remote network-based scenarios. If you took something which requires local access such as a privilege escalation vulnerability in Palo Alto, CVE-2023-3282 , then the scores vary more drastically.
This is because this vulnerability requires specific local conditions to be present (not previously considered under version 3.0) as well as more privileges and subsequent system impacts rather than direct impact on the system itself. With a score of 6.7 under version 3.0, this changes to 4.9 under CVSS4 – a sizeable drop that is more representative of the issue at hand.
Wrapping up
Overall, CVSS is supposed to help enterprises assess vulnerabilities at a glance, so they can effectively prioritize fixes. The new system has some notable improvements, and while I believe probably didn’t go far enough, it gives a better representation of exploitability so that companies know which vulnerabilities can hurt them, and which ones they can leave for another time.
The only question remaining is how quickly this new scoring system will be applied by security vendors so that we can benefit from this in the tools we use today.