GHSA improperly consumes and re-publishes CVE version metadata

[daniel-beck]

Whatever process is used to create GitHub Security Advisories does not consume version ranges from CVE metadata properly.

This results, for example, in GHSA-g975-f26h-93g8 claiming that version 2.24.2 is affected, when https://github.com/CVEProject/cvelist/blob/9a1d65a12274643c9bad407acb8368f2b60d2b5c/2022/43xxx/CVE-2022-43408.json#L22-L25 specifically excludes it.

This creates a ton of unnecessary confusion for users and false positive security scan results, and should be fixed.

[darakian]

Apologies about that. I've updated our advisory to reflect the CVE and I'll dig into what went wrong there. Thanks 👍

[daniel-beck]

@darakian Thanks! To clarify, the above is an example of a very common problem for us, there are almost 100 more CVEs in which we exclude backports since 2020, and almost all of them are improperly represented in their corresponding GHSAs. I reviewed our CVE entries that specify backports as exclusions from the range and list the results below. I hope this review/feedback helps you identify possible problems in the GHSA process.

That said, after thinking about this a bit, I consider CVE JSON v4 as underspecified. It does not seem to specify the semantics of overlapping version specifiers/ranges, other than the example being

"Product X between versions 10.2 and 10.8"

which probably involves a >= and a <= range (but might be !> and !< with no inclusion range at all). To keep ranges reasonable, we interpret it as exclusions taking precedence over inclusions for our otherwise straightforward ranges. That way, our metadata doesn't have to look like GHSA-rvg5-f5fj-mxvg which could result in reading/comprehension issues. If we're indeed wrong about this, I would appreciate if you could point us to the documentation for this.

Review of GHSA 2020-2022

• Correct 👍
  • CVE-2022-29036
  • CVE-2022-43408
• Correct affected ranges, but missing the latest fix version, only listing the backport
  • CVE-2022-29045
  • CVE-2022-29049
• Does not exclude backports, and additionally simplification of SHA-based version results in non-existent fix version, or potentially a bad affected range boundary
  • CVE-2022-20613 (affected)
  • CVE-2022-20614 (affected)
  • CVE-2022-25175 (fixed)
  • CVE-2022-43401 (affected)
  • CVE-2022-43402 (affected)
  • CVE-2022-43403 (affected)
  • CVE-2022-43404 (affected)
  • CVE-2022-43405 (affected)
  • CVE-2022-43407 (both)
• Does not exclude backports, and no fix version specified even though it was announced as fixed
  • CVE-2022-23106
  • CVE-2022-25179
  • CVE-2022-34176
  • CVE-2022-34177
• Does not exclude backports
  • CVE-2020-2252
  • CVE-2020-2279
  • CVE-2020-2299
  • CVE-2020-2300
  • CVE-2020-2301
  • CVE-2020-2305
  • CVE-2020-2306
  • CVE-2020-2307
  • CVE-2020-2308
  • CVE-2020-2309
  • CVE-2021-21648
  • CVE-2021-21649
  • CVE-2021-21650
  • CVE-2021-21651
  • CVE-2022-20615
  • CVE-2022-20616
  • CVE-2022-20618
  • CVE-2022-20619
  • CVE-2022-20620
  • CVE-2022-20621
  • CVE-2022-23107
  • CVE-2022-25173
  • CVE-2022-25174
  • CVE-2022-25176
  • CVE-2022-25177
  • CVE-2022-25178
  • CVE-2022-25180
  • CVE-2022-25181
  • CVE-2022-25182
  • CVE-2022-25183
  • CVE-2022-25187
  • CVE-2022-30947
  • CVE-2022-30948
  • CVE-2022-30952
  • CVE-2022-30953
  • CVE-2022-30954
  • CVE-2022-36881
  • CVE-2022-36882
  • CVE-2022-36883
  • CVE-2022-36884
  • CVE-2022-36885
  • CVE-2022-36886
  • CVE-2022-36889
  • CVE-2022-36890
  • CVE-2022-36891
  • CVE-2022-43409
• Unreviewed
  • CVE-2020-2253
  • CVE-2020-2254
  • CVE-2020-2255
  • CVE-2020-2258
  • CVE-2020-2302
  • CVE-2020-2303
  • CVE-2020-2311
  • CVE-2020-2322 (but this exclusion does not matter as it's not in the range, basically bad data from us but should not impact consumers)
  • CVE-2021-21621
  • CVE-2021-21623
  • CVE-2021-21626
  • CVE-2021-21641
  • CVE-2021-21647
  • CVE-2021-21678
  • CVE-2021-21680
  • CVE-2021-21684
  • CVE-2022-23105
  • CVE-2022-25184
  • CVE-2022-27195
  • CVE-2022-27196
  • CVE-2022-27197
  • CVE-2022-27198
  • CVE-2022-27199
  • CVE-2022-29041
  • CVE-2022-29047
  • CVE-2022-30945
  • CVE-2022-30946
  • CVE-2022-38663

[darakian]

Hey @daniel-beck,

Ya digging into this we ignore the cve product versions as they are a. uncommon and b. under specified leading to them being an unreliable source of information. We're in the process of migrating to CVE JSON v5 as well so, I don't expect our v4 support to change anytime soon.

For that list of CVEs I've made an internal issue for us to re-review them. I'll update you here when we can process them. Many thanks for letting us know 👍

[KateCatlin]

Hi @daniel-beck,

Just an update to let you know this is still on our list to backfill! We continually improve our database and the Curation team are constantly running these types of campaigns. This one just hasn't made it to the top of our list yet.

Thanks for your patience!

[daniel-beck]

All of GHSA-j664-qhh4-hpf8 GHSA-584m-7r4m-8j6v GHSA-rrgp-c2w8-6vg6 GHSA-hf9h-vv4m-2f33 GHSA-frgr-c5f2-8qhh GHSA-h76p-mc68-jv3p GHSA-cj6r-8pxj-5jv6 drop version exclusions defined in the original CVE JSON metadata, thereby improperly including (i.e. claiming to be affected) 2.387.x LTS releases of Jenkins.

It's not even the fault of CVE JSON v4 in this case, since there was no downconversion done by MITRE.

Bonus: Half of the entries don't have 2.375.4 as a fixed version despite the fix versions being identical for all of these.

[westonsteimel]

@daniel-beck does #2260 (comment) correct for CVE-2022-20613 or should version 1.34.2 be excluded as well? I didn't see 1.34.2 as excluded per the Jenkins announcement so have left it out for the moment

[daniel-beck]

I didn't see 1.34.2 as excluded per the Jenkins announcement so have left it out for the moment

We currently do not mention backports that are irrelevant for most users in end user announcements for easier readability (it gets messy fast). For full version information, see the CVE metadata at cve.org.

[westonsteimel]

Okay thanks, I'll start working through updating these using the assumption that the NVD CPE cve.org info will be correct

[daniel-beck]

Me:

_{(Admittedly, the 2.440.x line was a late addition preparing for our upcoming stable line with the backport, so that being unmentioned is, right now, fine.)}

GitHub:

I cannot even begin to guess what's going on here.

[darakian]

I cannot even begin to guess what's going on here.

Apologies about that. That was down to manual error on my part. I was reading from the NVD version of the CVE.
https://nvd.nist.gov/vuln/detail/CVE-2024-23897

Given that the LTS and regular releases are on the same maven artifact could I ask you for the affected ranges as opposed to the unaffected ranges?

[daniel-beck]

@darakian Thanks for your response!

The reference you provided doesn't list any versions ranges other than the prose I wrote for the CVE description, so I guess you mean that? I left out the 1.606 start of range given its obsolescence, but considering 2.427 through 2.441 unaffected would be wrong based on that as well (if you read the version ranges as independent, which is how we describe them for admins), and is far more relevant to admins keeping things up to date.

could I ask you for the affected ranges as opposed to the unaffected ranges?

Unsure what you're asking. I'd prefer to keep the approach chosen for future CVEs, as the "affected" ranges look quite messy if you're unwilling to mix release lines. But for programmatic consumers, it looks fairly straightforward:

• 1.606 through 2.426.2, both inclusive
• 2.427 through 2.440, both inclusive
• 2.441

(With the added problem that for another ~4 weeks or so there won't be a 2.440.1 fixed version.)

FWIW a similar problem exists for CVE-2024-23898 which has a different initial affected release but same fixed versions.

[darakian]

The reference you provided doesn't list any versions ranges other than the prose I wrote for the CVE description, so I guess you mean that?

Yep. That plus me trying to make what I thought would be a sensible combined range. Again sorry about that. 😞

Unsure what you're asking. I'd prefer to keep the approach chosen for future CVEs, as the "affected" ranges look quite messy if you're unwilling to mix release lines.

The CVE record you linked had versions listed as unaffected and I was asking for the inverse. What you provided looks great.

(With the added problem that for another ~4 weeks or so there won't be a 2.440.1 fixed version.)

That's unfortunate. I've updated our record and left the fixed version off for the time being. Let me know if you'd rather I put 2.440.1 on early 👍

FWIW a similar problem exists for GHSA-53ph-2r2x-vqw8 which has a different initial affected release but same fixed versions.

Reading from https://www.cve.org/CVERecord?id=CVE-2024-23898 the initial version on that one should be 2.217 right?

[daniel-beck]

That plus me trying to make what I thought would be a sensible combined range. Again sorry about that. 😞

No worries, was just really surprised about the lack of resemblance, especially as I was hoping CVE JSON v5's unambiguous version ranges (see previous conversation) would help with GHSA republishing. Thanks for the super quick followup 👍

Reading from https://www.cve.org/CVERecord?id=CVE-2024-23898 the initial version on that one should be 2.217 right?

Correct, 2.222.1 is part of that range by Maven rules.