Date: Sat, 30 Apr 2022 17:03:37 -0400 From: "David A. Wheeler" <dwheeler@...eeler.com> To: oss-security@...ts.openwall.com Subject: Re: CVE-2022-21449 and version reporting > On Apr 30, 2022, at 11:38 AM, John Helmert III <ajak@...too.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." >  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@...lendorf.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.