github
GHSA improperly consumes and re-publishes CVE version metadata
Whatever process is used to create GitHub Security Advisories does not consume version ranges from CVE metadata properly.
This results, for example, in https://github.com/advisories/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.
Apologies about that. I've updated our advisory to reflect the CVE and I'll dig into what went wrong there. Thanks 👍
@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
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 👍
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!
All of https://github.com/advisories/GHSA-j664-qhh4-hpf8 https://github.com/advisories/GHSA-584m-7r4m-8j6v https://github.com/advisories/GHSA-rrgp-c2w8-6vg6 https://github.com/advisories/GHSA-hf9h-vv4m-2f33 https://github.com/advisories/GHSA-frgr-c5f2-8qhh https://github.com/advisories/GHSA-h76p-mc68-jv3p https://github.com/advisories/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.
@daniel-beck does https://github.com/github/advisory-database/pull/2260#issue-1711656668 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
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.
Okay thanks, I'll start working through updating these using the assumption that the ~~NVD CPE~~ cve.org info will be correct
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.)
I cannot even begin to guess what's going on here.
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?
@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.
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 https://github.com/advisories/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?
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.217right?
Correct, 2.222.1 is part of that range by Maven rules.
. 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 👍
Ya, it's a pretty manual process on our end and while we try to minimize errors they do pop up. This issue has the upside of exposing a gap in how we're ingesting cve 5.0 data as well though, so there's some positivity there. Happy to get to this quick too. Timezones working out 🎉
Ok, https://github.com/advisories/GHSA-53ph-2r2x-vqw8 is also updated now. No fix versions on that one either. Please let me know if I've typo'd 🙇
Thanks for the updates!
FWIW fix versions 2.426.3 and 2.442 exist today for both. 2.440.1 will also have the fix, to be released in February. Whether that means no fix versions recorded until then because you have to touch these again anyway is you to you.
Went ahead and added 2.426.3 and 2.442. Should 2.440.1 be 2.441.1? 2.441 would come after 2.440.1 right?
@darakian
Went ahead and added
2.426.3and2.442.
Thanks!
2.441would come after2.440.1right?
In terms of version math, yes. Stable lines and backports mean that "version later" ≠ "date later" however, which is why the split ranges.
Should
2.440.1be2.441.1?
The forthcoming 2.440.1 stable release is also the reason I split the second and third range.
For context if you're very bored, https://www.jenkins.io/download/lts/
Every 12 weeks, the community will pick one of the relatively recent releases by consensus and mark it as the baseline for the next "stable but older" release line. Let’s say this was version X. We’ll create a branch from X to produce stable but older patch releases of X.1, X.2, and X.3. Changes to this branch will be restricted to backported cherry-picked bug fixes from the trunk that are "battle-tested" — meaning those commits that have already been a part of a main line release for more than a week. There are 3 minor releases for a baseline published in four week cycles.
2.440 is a recent weekly release we chose to be the next LTS baseline. We'll backport the security fixes into 2.440.1.
See how much easier this is by just specifying what versions are unaffected as I do on cve.org? 😁
I see. Would it make more sense to tell a user on the weekly release line to go to the next weekly rather than the next LTS though?
See how much easier this is by just specifying what versions are unaffected as I do on cve.org? 😁
Sorta no, but my brain is wired for affected versions so that's probably a me problem 😄 fwiw our system is also affected versions oriented as well hence the questions.
Would it make more sense to tell a user on the weekly release line to go to the next weekly rather than the next LTS though?
This is what we're doing, it's just that the pairs of (affected version range, fix version) in GHSA don't seem to map well to how we assign Jenkins versions. It seems either readable for humans, but not technically correct; or difficult to read, while programmatically consumable.
Our advisories skip some details (e.g., we didn't bother mentioning the release 1.606 from 2015 there) for easier consumption by administrators; while our CVE metadata is canonically correct and intended for programmatic consumption. Different content for different audiences, basically.
This is what we're doing, it's just that the pairs of (affected version range, fix version) in GHSA don't seem to map well to how we assign Jenkins versions.
Interesting. Ok, I'll have to rethink how we represent that on our side. We have a constraint where our "fixed" versions cannot be "lower" than the vulnerable version range.
Our advisories skip some details (e.g., we didn't bother mentioning the release 1.606 from 2015 there) for easier consumption by administrators; while our CVE metadata is canonically correct and intended for programmatic consumption. Different content for different audiences, basically.
Makes total sense to me. Write for your intended reader 😄