oss-sec mailing list archives
Re: CVE-2022-21449 and version reporting
From: "David A. Wheeler" <dwheeler () dwheeler com>
Date: Sat, 30 Apr 2022 17:03:37 -0400
On Apr 30, 2022, at 11:38 AM, John Helmert III <ajak () gentoo org> wrote: On Sat, Apr 30, 2022 at 01:24:36PM +0200, Christian Fischer wrote:It’s not that they didn’t/can’t verify, it’s already verified,they’re claiming those versions no longer being officially supported means they can seemingly omit them from CVE reporting.Which is dangerous, misleading, and nonsensical.While i fully agree with this be aware that CVE entries could generally contain incomplete information:...
CVEs are practically *guaranteed* to have incomplete information, no one knows all & time is limited even if something *can* be found. No one should be *required* to determine if some unsupported versions are vulnerable to a reported vulnerability. HOWEVER: if important information is *already known* then it should be incorporated into the CVE data (either originally, or added to the relevant databases later when that becomes known). That way the database represents a common basis for what *is* known. That's how I interpret the quoted CNA rules:
"8.2.1 MUST provide enough information for a reader to have a reasonable understanding of what products are affected. If the affected products are not explicitly listed in the description, then the CNA MUST provide a reference that points to the known affected products." [1] https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_8-2_cve_record_prose_description_requirements
I read that as saying that if a version is *known* then it should be included. Of course, if Java implementations 7, 8, and 11 didn't have this vulnerability then it shouldn't be listed (maybe it's not). But I think it's important to note that CVE information should have the "best information available at this time & is subject to improvement". I don't think we need to record vulnerabilities in MS-DOS 1.0, because I expect that to have a small deployed base. But if an old unsupported version has a non-trivial installed base, then including known information about them *should* be provided. If nothing else, it incentivizes organizations to update - and we *often* have trouble getting organizations to update. On Thu, 28 Apr 2022, Seaman, Chad wrote:
In what universe exactly are versions omitted from vulnerability reporting because a vendor “no longer supports that version”… this non-supported version is still vulnerable?
On Apr 28, 2022, at 10:40 AM, Brian Behlendorf <brian () behlendorf com> replied:
If that universe were consistent, it'd be one where vendors and open source projects issued pre-emptive CVEs when release branches are no longer provided with security fixes.
I'm skeptical that CVEs *specifically* are the best mechanism for reporting "support has ended". But I *completely* agree with you that there should be an automated mechanism for capturing what is or isn't still a current/supported version, to make it easy to answer "which components are no longer supported?". For some components "only the latest version is supported", but that's not true for many others. Components that will no longer receive security fixes are a ticking time bomb. --- David A. Wheeler
Current thread:
- CVE-2022-21449 and version reporting Seaman, Chad (Apr 28)
- Re: CVE-2022-21449 and version reporting Brian Behlendorf (Apr 28)
- Re: CVE-2022-21449 and version reporting Jeremy Stanley (Apr 28)
- Re: CVE-2022-21449 and version reporting Seth Arnold (Apr 28)
- Re: CVE-2022-21449 and version reporting Sven Schwedas (Apr 28)
- Re: CVE-2022-21449 and version reporting Seaman, Chad (Apr 28)
- Re: CVE-2022-21449 and version reporting Christian Fischer (Apr 30)
- Re: CVE-2022-21449 and version reporting John Helmert III (Apr 30)
- Re: CVE-2022-21449 and version reporting David A. Wheeler (Apr 30)
- Re: CVE-2022-21449 and version reporting Christian Fischer (Apr 30)
- Re: CVE-2022-21449 and version reporting John Helmert III (May 01)
- Re: CVE-2022-21449 and version reporting Christian Fischer (May 02)
- Re: CVE-2022-21449 and version reporting Sven Schwedas (Apr 28)
- Re: CVE-2022-21449 and version reporting Iron-Bound (Apr 29)
- Re: CVE-2022-21449 and version reporting Jeremy Stanley (Apr 30)