[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFRnB2VB6htDEL2u1uNQbA1q_VugPeuqegSdBbdvb-XzNOqbeg@mail.gmail.com>
Date: Tue, 25 Jun 2019 09:46:39 -0400
From: Alex Gaynor <alex.gaynor@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz
20% was a completely made us number.
Alex
On Tue, Jun 25, 2019, 9:42 AM Bob Friesenhahn <bfriesen@...ple.dallas.tx.us>
wrote:
> On Mon, 24 Jun 2019, Alex Gaynor wrote:
> > - 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?
>
> I see the assumption that 20% of oss-fuzz reports are exploitable
> vulnerabilities. Where does this percentage estimate come from? What
> does it mean to be "exploitable"?
>
> From working on fixing oss-fuzz detected bugs in GraphicsMagick I see
> that many/most of the issues are not significant from a security
> standpoint, assuming that the software is deployed in a way suitable
> for its level of exposure. Common issues include:
>
> * Huge uninitialized memory allocations (which do not really matter
> under Linux since Linux does not reserve anything but virtual
> memory space).
>
> * Consumption of uninitialized data (e.g. image data) which is not
> used to make important decisions. This is usually due to unhandled
> cases or error handling which does not quit immediately.
>
> * Tiny heap over-reads which are not past the bounds of the
> underlying allocation.
>
> * Heap over-reads or over-writes which cause an immediate core dump.
>
> * Excessively slow code with the slowness emphasized by ASAN and
> UBSAN code running vastly slower. The excessively slow code is not
> necessarily noticeable in a normal compilation.
>
> * Memory leaks.
>
> * "undefined behavior" which nevertheless has a common behavior that
> compilers have followed since the dawn of time.
>
> The most important thing that oss-fuzz contributes is a large
> collection of files which cause problems for unfixed software such
> that only the unaware or foolish do not update to fixed versions.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen@...ple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>
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.
