[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1hfSKS-00015J-V5@rmmprod07.runbox>
Date: Mon, 24 Jun 2019 13:00:28 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
> On Mon, 24 Jun 2019, Bob Friesenhahn wrote:
> > Most oss-fuzz issue detections are not CVE worthy. For example, a one-byte
> > read "heap overflow" is not likely to cause any actual harm but oss-fuzz
> > would classify it as "heap overflow".
On Mon, 24 Jun 2019 11:59:43 -0400 (EDT), "Stuart D. Gathman" <stuart@...hman.org> wrote:
> Nevertheless, it is a bug. Fuzzers are amazing. Going forward, the
> best plan is for more projects to include fuzzing as part of the
> build process testing.
It is a bug, fuzzers are amazing, and more projects should include fuzzing.
But CVEs are supposed to only be assigned to vulnerabilities or exposures.
Many bugs are not vulnerabilities or exposures that lead to vulnerabilities.
If a bug *is* a vulnerability, then yes, it should have a CVE assignment,
and there are clearly a lot of vulnerabilities without CVE assignments.
In particular, many organizations have a rapid upgrade process
if some software version has a CVE, and a slow process otherwise.
(There are things that need doing besides upgrading software.)
If a particular version of software has a serious vulnerability, it needs at least one
of the most serious vulnerabilities assigned a CVE so that people will upgrade
it more rapidly. In the end, the goal should be to get software fixed
*and* deployed - if it's not deployed when it needs to be, it didn't help.
Downstream needs to do their part by being prepared to upgrade... but
suppliers need to make it clear why something needs to be upgraded quickly
(if that's the case) so that the faster process will be used.
We should be focusing on the "final impact", that is,
we should be trying to reduce the cases where an attacker can exploit
a known vulnerability in deployed software... *without* breaking the bank.
--- 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.
