CVSS vector/score in assessments

[cip999]

It has been proposed to add a CVSS field to the assessments, which is mainly helpful to organizations subject to compliance requirements and that need a standardized measure of CVE severity.

This is the tracking issue for the proposal. I encourage everyone to discuss pros and cons of it.

[bjoernd]

I think we have most of the data already. Looking at the CVSS base metrics:

• Attack Vector -- I think this corresponds to the 'reachability' element we already have in the template
• Attack Complexity -- this would right now be captured in a Notes field
• Privileges Required -- already present in our template
• User Interaction -- I guess most of the time kernel CVEs will have UI:None anyway?
• Scope -- somehow maps to bug classes in the existing template, can likely be adjusted
• CIA impact -- this is a more fine-grained breakdown of the impact field we already have.

[dmell]

I'm sorry, this is a long-overdue answer.

My main concern is that the CVSS vector fails to capture the complexity of a kernel vulnerability. Let's break down the fields.

• Attack Vector: there is no difference between a local bug, and a VM-reachable one. I argue that this is quite relevant, but happy to hear everyone's thoughts on this.
• Attack Complexity: quoting from the specs, this describes "the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability". Perhaps a value different than low can be enough to express that something non-trivial is required for successful exploitation, but I'm afraid figuring this out requires deeply analyzing the bug and understanding how it can be triggered. I'd love to better understand what the review process looks like from who is currently doing this.
• Privileges Required: agreed. Our template actually allows to mention it if a specific capability is missing, instead of a generic "high", but it's only a minor difference.
• User Interaction: agreed.
• Scope: I'm not sure how we can map it to bug classes. According to the definition, I feel like this should always have the same value for a kernel CVE.
• CIA: agreed.

When I say CVSS can't frame a kernel bug properly, in addition to the comments above, I also mean that some information is really just missing. For example, how can we distinguish a DoS that is caused by a WARN_ON versus an actual DoS, say a null pointer deref?

On the other hand, let me repeat that I'm aware of how central CVSS is in our industry, and that we can't just move away from it if we don't like it. I wonder if this effort can be a useful intermediate/alternative layer to CVSS, where we perform a more kernel-oriented analysis that is still useful to who produces CVSS vectors, and allows them to contribute too. I feel like going through the template may even be seen as an intermediate step to creating the vector: one first needs to figure out what vulnerability they're looking at, and understanding things like memory_corruption and bug_class sound like prerequisites to then fill the CVSS fields.

[gregmarsden]

What I appreciate about the linux-cve-analysis effort to date is its focus on objective, factual descriptions of the vulnerability. It is the base analysis that's always required to understand the severity of a given vulnerability, but the analysis stops before adding in subjective measures or environment-specific or configuration-specific factors. This separation allows us vendors to pool our efforts at understanding vulnerabilities, accelerating vulnerability reviews by allowing reviewers to start from a shared initial starting point.

I don't think adding CVSS scores will help that goal, as I expect the various contributors will legitimately end up with varying CVSS scores for the same vulnerability. I expect that each of us will be computing and publishing our own CVSS scores for each vulnerability, and I would not expect those scores to necessarily align. Having a CVSS score included in the linux-cve-analysis repo, no matter how well-intentioned, would only cause additional problems/questions for vendors whose scores may differ from the centralized, published score.

While adding some CVSS vectors to kernel CVEs may be helpful, we've also found plenty of cases where using CVSS style vector options can be more vague than specific: for example, when dealing with privilege escalations across a virtualization boundary, or for a privileged user working around secure boot lockdown features. In these cases, the CVSS score would differ based on whether the user depends on secure boot as part of their security boundary, and could meaningfully impact the choice of quantized vectors.

[rkeshri-RH]

I wanted to propose following:

1. Privileges_required: Should be more direct (and not a boolean)

• unauthenticated
• authenticated
• privileged

2. Impact: should include (for majorly seen in hardware flaws)

• scope escape

3. Mitigation: This is new but very effected (and can be empty if we do not have one)

[gregmarsden]

I've spun off an issue specific to Privileges_required

for hardware flaws, those typically dont come out of the Linux CNA so will usually be handled by different processes. Same with un-mitigated vulnerabilities; every Linux CNA assigned vulnerabilities is guaranteed to have a fix, as the CVEs are assigned after the patches are merged upstream.

On the call yesterday, there was general agreement that CVSS scoring was use-dependent, and that this project is focused on factual descriptions of vulnerabilities. Is it OK to close this issue?

[gregmarsden]

Added a note regarding CVSS scoring to the project README. This issue can be closed.