Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master cf142c6: Get Wireshark to compile

From: Evan Huus <eapache@xxxxxxxxx>
Date: Sat, 24 Jan 2015 22:20:31 -0500
> On Jan 24, 2015, at 17:43, Gerald Combs <gerald@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
>>> 
>>> cf142c6 by Gerald Combs (gerald@xxxxxxxxxxxxx):
>>> 
>>>   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@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe