[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFRnB2XeQ-casQLm0MRCdRmQ5aeF9K=X3Km5eYg9DB6A915d5A@mail.gmail.com>
Date: Mon, 24 Jun 2019 19:15:20 -0400
From: Alex Gaynor <alex.gaynor@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz
I figured it'd be useful to summarize the themes I think I'm hearing:
- Greater automation around requesting CVEs so that when there really are a
lot of vulnerabilities they can be requested easily and have most of the
details filled in by automatic systems like syzbot of ClusterFuzz.
- Better automation around assessing exploitability -- I confess this one
sounds very hard to me, at least without requiring more user involvement
than ASAN requires right now. This seems like a very cool area for academic
research though!
- Not having sooooo many vulnerabilities. While there's some dispute over
just what % of the bugs that OSS-Fuzz and syzbot turn up are exploitable,
there's no doubt that they find a _lot_ of them. Even if only 20% of
OSS-Fuzz reports were truly exploitable vulnerabilities, that'd still be
>600 of them. We can't produce this many vulnerabilities and then try to
clean up afterwards by finding them with fuzzing -- at some point the
number of vulnerabilities simply overwhelms us. Tactics for reducing
vulnerabilities in the first instance, like memory safe languages, are an
important part of making this problem tractable.
Do folks feel like there were important themes that this misses?
All of these seem actionable, in their own way, which I like.
Alex
On Mon, Jun 24, 2019 at 3:32 PM Simon McVittie <smcv@...ian.org> wrote:
> 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
>
--
All that is necessary for evil to succeed is for good people to do nothing.
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.
