[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Jun 2019 20:30:48 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
On Mon, 24 Jun 2019 at 13:00:28 -0400, David A. Wheeler wrote:
> 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.
I think you might have also been implying this, but just to say it
explicitly: if a particular version of software has lots of fixed bugs,
but they are not exploitable vulnerabilities in practice, then it would
be counterproductive to try to fast-track upgrades (trick people into
using their rapid upgrade process) by assigning CVE IDs to those bugs.
Fast-tracking upgrades of packages with CVE fixes is only going to happen
as long as it's still a rational strategy for balancing vulnerability
exposure against the risk of regressions. If lots of CVE IDs get assigned
to issues that aren't exploitable in the real world, then that will teach
consumers of software that they can safely ignore "most" CVEs, which
will tend to result in some issues that *are* exploitable being missed
and not fixed on deployed systems. Everyone loses (except attackers).
This is a particularly interesting trade-off for denial-of-service
vulnerabilities, because regressions caused by flawed fixes for
vulnerabilities often cause denial of service. (This is often a crash,
but not necessarily - addressing local DoS vulnerability CVE-2014-3637
in dbus led to some machines not booting reliably, denying service to
rather more people than the original vulnerability.)
In the worst case, a flawed fix for a vulnerability might contain a
regression that is a more serious vulnerability.
smcv
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.
