1

I've recently been given a set of guidance notes on CVSS; but the guidance isn't making sense. I've sent a query off, but got no response. So asking here.

Say you have an exploit (can ignore base for now – but if you want to replicate, I’ve got: CVSS v3.1; AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L )

Problem is in temporal metrics:

Stage #1 Original exploit is

  • Raised by proof-of-concept (say someone external sending in details).
  • No fix available
  • Report confidence is unknown as its external.

Temporal score is 5.5; overall score is 5.5 [I've put nothing on environmental yet]

.

Stage #2 You implement a workaround in CVSS parlance. Now temporal is:

  • Proof-of-concept (that is the only thing available “in the wild”)
  • Workaround
  • Report confidence is high as you have internally recreated the problem

Temporal score is now 5.8 (despite the workaround) ?!

.

Stage #3 Then you implement a full fix. Now temporal is:

  • Proof-of-concept (that is the only thing available “in the wild”)
  • Official Fix
  • Report confidence is still high as you have internally recreated the problem

Temporal score is now 5.7. ?!?!?!?!?!?

The guidance I've been given states that the exploit maturity and report confidence remain unchanged. So according to that and to CVSS, you’d have been safer sitting on yer ass at stage 1 above and doing nothing? I’m obviously missing something – but what?

If, after you’ve released your patch, exploit maturity and report confidence are meant to drop (to unproven and unknown respectively), that’d make sense as the attackers now have to start from scratch. But that is not what my guidance is telling me.

Anyone willing and able to shed some light on it for me please?

0

2 Answers 2

1

If i calculated all right with the official calculator you are using CVSSv3.0, there is CVSSv3.1 available whichs gives minimal different temporal values (I calculated my values with CVSSv3.1): base: 6.3

  1. Stage: 5.4
  2. Stage: 5.7
  3. Stage: 5.6

In the company i am working we only rely on the base score to prioritize vulnerability patching, because this value says, how severy the vulnerability is. The problem with the tmeporal score is, that it represents a kind of overall view of vulnerabilities.

So a vulnerability is more critical, if the poc is available and confirmed, than a vulnerability with an unconfirmed poc, because you are not shure, if the poc really works. So if the poc is confirmed it increases the value, the workaround decreases a bit (without workaround it would be 5.9 instead of 5.7, so here you can see how valuable the 'confirmed' is)

The official patch decreases the value, as expected.

The guidance I've been given states that the exploit maturity and report confidence remain unchanged. So according to that and to CVSS, you’d have been safer sitting on yer ass at stage 1 above and doing nothing?

No. From the occicial site:

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence in the description of a vulnerability.

It does not lower the criticality of the vulnerability, it rather puts the vulnerability into a context of available pocs and fixes. For me this only makes sense in an overall view of vulnerabilities in the world, but not for a company to prioritize fixing.

As example: if you have a vulnerability which has a confirmed poc and a fix, the temporal score lowers the overall score. It looks like the vulnerability is not that high, but that's only true, if you compare to a similar vulnerability with confirmed poc and without fix. For a company with both vulnerabilities, these are (for me) equal severe, because both have confirmed pocs. The point is, i know that i can install the one fix, but until i install this, it's not better for me that a fix is available. For me it sometimes can be even worse, if a patch is available and do not install, because with a patch it is easier to create a exploit.

If, after you’ve released your patch, exploit maturity and report confidence are meant to drop (to unproven and unknown respectively), that’d make sense as the attackers now have to start from scratch.

No. The vulnerability is existing in a specific version of your software, so the vulnerability still exists in this software version and is fixed in the next. So the exploit maturity etc. remain the same, because these values rely on the old version. In the new version the vulnerability is not existing, so you do not have to reduce any values for this.

To make it clear, the temporal score does not lower the severity of a vulnerability for you, it helps comparing vulnerabilities in general.

Edit: The score, especially the temp score, is not build for the vendor, instead it is build for the user. Often the score is build with help of the vendor. Of course a vendor can priotize with cvss score, too. The main thin to your question from the documentation of "report confidence":

The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.

and from the "confirmed" status:

Source code is available to independently verify the assertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.

The point is, that the "confirmed" state is given, if you can prove it (reproducable), or get it confirmed by the vendor. As a vendor you have the best position to adjust the temp. score, so you should update the official temp. score if you know, that the vulnerability is there and you have a working exploit (leads to E:/F for functional exploit). If the exploit existing

and details are widely available

it leads to E:H (here it means publicaly). But in both cases you have RC:C

4
  • So a temporal score is almost more rating up the exploit for the consumer of the software rather than the developers? [i.e. there is a hole, we now have a patch, but that means everyone knows about the hole and can maybe reverse engineer a full exploit. You need to update your S/W.]
    – Amiga500
    Nov 5, 2021 at 8:21
  • @Amiga500 The temporal score is something misleading. It never increases the base score. If you take the highest values of the temporal metrics (E:H/RL:H/RC:H) you get always the base score (it's the same as if you take all not defined). So even if you have a confirmed poc and no patch it decreases value and that's why you should not rely on the temporal score so much. I think it confuses more than it helps, if you only look at the calculated values instead of the vector. From the vector you can read a bit more and use it for your own classification
    – D-E-N
    Nov 5, 2021 at 10:08
  • Following up - I'm wondering is my assignment (and the guidance assignment) of "Report Confidence" correct. In discussing report confidence, there are numerous mentions of "published". Does that infer "published into the public domain"? In which case, RC would remain as unknown - and it doesn't reflect the internal workings of your devs?
    – Amiga500
    Nov 8, 2021 at 8:27
  • I edited my answer
    – D-E-N
    Nov 8, 2021 at 17:14
0

To answer the question why is the score higher indicating a higher risk after a fix?

Because having a patch available is a larger risk to those who are unpatched.

Now there's a patch, someone who previously was unaware any problem exists now knows the problem exists AND if they have malicious intent can (sometimes trivially) learn how to exploit by reversing the patch

Again, its a higher risk for unpatched users, once you're patched the cvss has no meaning to you

And the reason the score remains virtually unchanged for a workaround is the risk is not significantly changed for those who do not apply the workaround. I.e. for a workaround to be actually a workaround, applying it would mitigate the risk! I.e. like a patch, if you apply a workaround the cvss is of no further use to you.

A workaround is not very useful for reverse engineering, it's not always clear where the flaw is, and if it has a clue where and what a flaw might be it doesn't give any indication how to exploit it exactly. This is why a patch increases the overall risk score more than a workaround would. And having neither means many malicious actprs have no way to know about a flaw or if they know a flaw exists without a patch to reverse engineer effort isn't an option.

You are not "better off" sitting on your hands, every day you have the flaw is a risk, every day you're not patched when a patch exists is a higher risk. It doesn't mean you should not be concerned about the vulnerability before a patch exists, it just means the risk applies to you even when there is no patch and when a patch exists you can't afford to sit idle any longer because reversing the oatch is fast and now the risk to you is greater

Temporal scores are mostly informative, the vulnerability itself doesn't change or the rosk the exploit poses also doesn't change, no matter what temporal elements exist. with the main goal of temporal is to assist in remediation prioritisation. If in triage you have temporal information, you can effect positive change easier than if all you had was a base score

4
  • "with the main goal of temporal is to assist in remediation prioritisation. If in triage you have temporal information, you can effect positive change easier than if all you had was a base score" Is that prioritisation and triage performed by the consumer rather than creator?
    – Amiga500
    Nov 5, 2021 at 8:27
  • Indeed. A CVSS provided by the vendor is scored entirely informational. It can never be treated literally because the author is completely in the dark about your implementation and production environment. A vendor cannot know if the code paths even use the vulnerable functions for example, you may have a vulnerable version and never run the vulnerable code. You may also have a firewall or waf in plave preventing the attack entirely, the author cannot know this. Cvss is 20% author, 10% vendor 70% consumer approximately
    – Stof
    Nov 5, 2021 at 9:15
  • Sry but you are wrong with some stuff, based on CVSS. The official patch does not increase the score compared to workaround, it's the opposite! On the given values of the poster there change multiple values and the confirmation of the poc is increasing the values. The official patch decreases it a little bit (see my answer) and if you play around with the official v3.1 calculator you can see directly what happens if you only change official patch and workaround. That a patch can easier misused for exploits is correct, but is not reflecting by the temporal score
    – D-E-N
    Nov 5, 2021 at 9:26
  • if a patch exists, i can reverse engineer it to become an exploit. if a patch is not available I have no means to create an exploit. which is the higher risk? i.e. I go to teh cvss calculator and adjust accordingly to make the score appropriate. you are in control of cvss as the user of cvss, the author is just a starting guide and 100% ignorant to your existence let alone what effects your implementation. all as I explained. and the cvss score is what you enter, not what is entered for you, doing it that way you are misusing cvss fundamentally
    – Stof
    Nov 5, 2021 at 11:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .