[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CCD51EB4-A0CF-457D-B1B5-4516779AE4C8@dwheeler.com>
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."
> [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@...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.
