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.