[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz
From:       Bob Friesenhahn <bfriesen () simple ! dallas ! tx ! us>
Date:       2019-06-25 13:41:08
Message-ID: alpine.GSO.2.20.1906250816590.2070 () freddy ! simplesystems ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]