[Peter Wu <peter@xxxxxxxxxxxxx>]

Hi Michael,

On Fri, May 05, 2017 at 09:50:04AM -0400, Michael Mann wrote:
> 
> Peter,
> 
> I'm not sure if this is a conversation for -dev,

(I think -dev is good, adding in cc.)

> but I'm just curious myself - what is the "status" of oss-fuzz?  It
> feels like the bugs being logged are grouped into "categories" and a
> new "category" shows up about every week.
> Are you adding a category at a time, and then try to fix the bugs from
> that category before moving on?  Are the fuzzes just that different
> than current fuzzbots that it'll just be awhile before it levels out
> (and the bugs start to dry up)?
> 
> Michael

Some history: Jakub added oss-fuzz integration (starting with
https://github.com/google/oss-fuzz/pull/532, later updated with more
dissection tables in https://github.com/google/oss-fuzz/pull/533 and
finally moved to the WS tree in tools/oss-fuzzshark/).

I have done little to tune oss-fuzz, Google's fuzzing cluster
("clusterfuzz") just discovers issues automatically. I think there is an
option to build a corpus (Jakub is building one at
https://bitbucket.org/jwzawadzki/wireshark-fuzzdb I believe).

So far, we have seen these report types:

 - Undefined behavior from large or negative shifts (not too bad).
 - buffer overrun (read) by a small amount. Mostly harmless and in some
   cases it actually requires a special patch to reproduce:
   https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13608#c2
 - Timeouts. These are more severe as it causes a denial of service due
   to "infinite" loops.
 - Stack overflow. Denial of service due to deep recursion. Bad.
 - Null pointer dereference. More about this later.
 - Out-of-memory. Request for malloc((guint32)-1), bad memory
   management, etc.
 - (Direct) memory leaks.

So about the null pointer dereference, that happened due to unexpected
layerings, one protocol for example always expected to be layered on top
of IP which was not always the case because oss-fuzzshark would call a
dissector directly through its dissector table ("udp.port" or
"ip.proto"). For the reproducers, I have emulated this by crafting
packets using the Upper Pdu ("Export PDU") encapsulation (which is not
supported by 2.0 though, so the pcaps cannot be used to reproduce
crashes with 2.0).

These issues were found without trying very hard (the very first report
was the result of mutating an x86 executable... rather than a valid
protocol message). I don't know how our own fuzzer exactly works, but
oss-fuzz uses libFuzzer and AFL, both of them are smarter and add
compile-time instrumentation which guide the fuzzing process.

My current workflow is:

 1. Check mail, notice one or more oss-fuzz reports.
 2. If it is a new report, download reproducer and run my script to
    reproduce it. If reproduced, it will automatically file a new bug.
    For updates to an existing oss-fuzz issue, try to validate that the
    bug was indeed fixed.
 3. Archive the mail.

Until I get around publishing the scripts and further documentation,
here is a list of all reported (open/closed) issues:
https://bugs.wireshark.org/bugzilla/buglist.cgi?bug_status=__all__&columnlist=resolution%2Cshort_desc%2Cbug_file_loc%2Cchangeddate&content=%22%5Boss-fuzz%5D%22&order=bug_file_loc

Here are all open oss-fuzz issues:
https://bugs.wireshark.org/bugzilla/buglist.cgi?resolution=---&content=%22oss-fuzz%22&columnlist=product%2Ccomponent%2Cbug_status%2Cresolution%2Cshort_desc%2Cbug_file_loc%2Cchangeddate
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl