check-cves should compute and display CVSS score for triage

[Steve Beattie]

Since we have gone down the path of including the nvd provided CVSS score in our cve tracker data, it would be useful to display the computed score or the essential elements from the included cvss score in check-cves during triage.

(Something to make it easier to figure out how to interpret a given CVSS score during re-triage would be useful, too, but we generally don't use tools for that.)

[Alex Murray (alexmurray)]

Added in https://git.launchpad.net/ubuntu-cve-tracker/commit/?id=1a2e3750ef22c12e061f49062e9cb43a32646228

[Alex Murray (alexmurray)]

Since we parse out the full attributes of the score, we could easily try and show more than just the vector string and the base score but I am not sure how we could do this in a concise manner - so currently this will look like either of the following, depending on whether using traditional or experimental output modes:

---------------------------------------------------------------------------------------------

***********************************************************************
 CVE-2020-10134 (1/25: 4%)
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10134
***********************************************************************
 Published: 2020-05-19 16:15:00 UTC
 CERT-VN: VU#534195 https://kb.cert.org/vuls/id/534195/
 CONFIRM: https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/
Pairing in Bluetooth® Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates different pairing methods in each peer device and an end-user erroneously completes both pairing procedures with the MITM using the confirmation number of one peer as the passkey of the other. An adjacent, unauthenticated attacker could be able to initiate any Bluetooth operation on either attacked device exposed by the enabled Bluetooth profiles. This exposure may be limited when the user must authorize certain access explicitly, but so long as a user assumes that it is the intended remote device requesting permissions, device-local protections may be weakened.
 CVSS (nvd): CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N [6.3]
Debian CVE Tracker: None
 NOTE: Bluetooth protocol issue
A]dd (or R]epeat), I]gnore forever, S]kip for now, or Q]uit? [skip]

---------------------------------------------------------------------------------------------

# CVE-2020-10134
#
# Published: 2020-05-19 16:15:00 UTC
#
# CERT-VN: VU#534195
# https://kb.cert.org/vuls/id/534195/
#
# CONFIRM: https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/
#
# Pairing in Bluetooth® Core v5.2 and earlier may permit an unauthenticated
# attacker to acquire credentials with two pairing devices via adjacent
# access when the unauthenticated user initiates different pairing methods in
# each peer device and an end-user erroneously completes both pairing
# procedures with the MITM using the confirmation number of one peer as the
# passkey of the other. An adjacent, unauthenticated attacker could be able
# to initiate any Bluetooth operation on either attacked device exposed by
# the enabled Bluetooth profiles. This exposure may be limited when the user
# must authorize certain access explicitly, but so long as a user assumes
# that it is the intended remote device requesting permissions, device-local
# protections may be weakened.
#
# CVSS (nvd): CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N [6.3]
#
# Debian CVE Tracker: None
#
# NOTE: Bluetooth protocol issue
#
# CVE-2020-10134 ignore "Bluetooth® Core"
#
CVE-2020-10134 skip

--------------------------------------------------...

[Steve Beattie (sbeattie)]

On Thu, May 28, 2020 at 03:12:39AM -0000, Alex Murray wrote:
> Since we parse out the full attributes of the score, we could easily try
> and show more than just the vector string and the base score but I am
> not sure how we could do this in a concise manner - so currently this
> will look like either of the following, depending on whether using
> traditional or experimental output modes:

Thanks. On the one hand, I can't get my brain to grok the random string
of single letters. On the other, I'm not sure the number tells me much
either. I did have the idea of maybe reporting something like:

  Confidentiality: [high|medium|low] Integrity: [high|medium|low] Availability: [high|medium|low]

as I tend to think of those as the most relevant portions of the CVSS
array elements. But that may be a bias that I have, and am open to other
thoughts here.

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

[Alex Murray (alexmurray)]

For just CIA, these are the last 3 elements of the string - so taking the one in comment:2 as an example:

C:H/I:L/A:N

Confidentiality: high
Integrity: low
Availability: none

I suspect with a bit of practice we can get used to parsing these but I agree it is quite hieroglyphic until you have had to do it slowly and manually a bunch of times. At least for these 3 I can usually remember them - the other elements I have a harder time with.

I am totally open to making this more verbose though, I just couldn't think of a great way to do it.