Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz

[Bob Friesenhahn <bfriesen () simple dallas tx us>]

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 () simple 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