Re: [Wireshark-commits] master cf142c6: Get Wireshark to compile with afl-gcc.

[Evan Huus <eapache () gmail com>]

> On Jan 24, 2015, at 17:43, Gerald Combs <gerald () wireshark org> wrote:
>
> > On 1/24/15 1:28 PM, Guy Harris wrote:
> >
> > > On Jan 24, 2015, at 11:14 AM, Wireshark code review <code-review-do-not-reply () wireshark org> wrote:
> > >
> > > cf142c6 by Gerald Combs (gerald () wireshark org):
> > >
> > >   Get Wireshark to compile with afl-gcc.
> > >
> > >   Fix errors found by American Fuzzy Lop's afl-gcc
> > >   (http://lcamtuf.coredump.cx/afl/):
> > >
> > >   peektagged.c:
> > >   error: 'fileVersion' may be used uninitialized in this function
> >
> > So did AFL generate a test case for this one?  I'm not sure where it could ever be used uninitialized, given that 
> > wtap_file_read_number() should, if it returns a value that's neither -1 nor 0, fill in the variable to which it's 
> > handed a pointer; perhaps afl-gcc's data flow analysis missed something, or perhaps I did.
>
> These were fixes that had to be made prior to fuzzing. As far as I can
> tell they fall into the "squelch a compiler warning" category. afl-gcc
> generates an instrumented executable, which you can then run under
> afl-fuzz (the actual fuzzer). According to the documentation the
> instrumentation isn't strictly necessary but it does enable more
> intelligent and efficient fuzzing.
>
> BTW, I haven't found anything yet, but it looks like Evan has
> (gb2a5f15).

That was (like Gerald's) just a compiler warning to be squelched on the path to getting it built. I'm still playing 
with flags and haven't really run a proper fuzz pass yet.

AFL calls through to your existing gcc, it just instruments and sets its own batch of flags along the way. It's 
entirely possible that the errors it's causing are legitimate, but only exist when the additional instrumentation is in 
place.

> Hopefully we can add an AFL step to the buildbot at some
> point but I'm not sure if that's feasible with the current version.

My gut says that the input will have to be much more carefully curated than our current "ALL THE CAPTURES" approach 
(>5000 at last count). AFL seems to prefer fewer, smaller starting points, something like:
- one file for each capture type we support, containing a single instance of each record type (for file types like 
pcapng that support different record types)
- one short TCP conversation of just one or two data packets
etc.

It's not aware of capture formats, so it will give wiretap much more of a workout, but will probably be less efficient 
for the dissection engine.

> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe