Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Nov 2014 05:30:36 +1300
From: Amos Jeffries <>
Subject: Re: Fuzzing project brainstorming

Hash: SHA1

On 21/11/2014 4:50 a.m., Hanno Böck wrote:
> Am Thu, 20 Nov 2014 08:38:38 -0700 schrieb Kurt Seifried:
>> The most important part of all: who's going to interpret the
>> fuzzing results and then co-ordinate with upstreams to make
>> source code fixes?
> Well, the answer to that is: the people who do the fuzzing.
> My main aim is to make more transparent what's already going on.
> That's not going to change who does the fuzzing and how it gets
> reported.
> There lays deeper a question that I asked myself already: What's
> an "okay" way of reporting these things? Basically what I usually
> did is just sending crash samples to upstream devs and add some
> valgrind/asan output. One could argue that I'm offloading the real
> work to the upstream devs, however I feel they know their code
> better than I do (and often I'm just not qualified to create the
> fix). Until now I feel most upstreams were okay with that.

Speaking as an upstream maintainer...

So long as the report has a full crash trace with symbols and values
they are usually easy enough for someone upstream to fix or at least
understand what is the underlying problem to be worked on.

The biggest problems we (upstreams) have with trace reports is often
submissions are made with just long lists of raw memory address
references for functions on the stack/heap, critical variable symbols
and values optimized away by the compiler etc. Traces like that are
pretty much wasted reports of "it crashes" ... um.

- From a security perspective, if you are going to push these traces
upstream as a vulnerability (or not) then there had better have been
some triage to see if it actually is one. That analysis will give you
some more details to add to the report in the way of ideas about what
should be expected to happen instead of crash. Anything like that
which can save upstream time is useful.

Since they are coming from fuzzing a copy of the exact input which led
to it is also valuable. There is nothing worse than having to guess at
what might have led to a crash when the input could literally have
been anything at all.


Version: GnuPG v2.0.22 (MingW32)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.