[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Nov 2014 05:30:36 +1300
From: Amos Jeffries <squid3@...enet.co.nz>
To: oss-security@...ts.openwall.com
Subject: Re: Fuzzing project brainstorming
-----BEGIN PGP SIGNED MESSAGE-----
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.
HTH
AYJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUbhcsAAoJELJo5wb/XPRjZgcIAKrX9zOPTyQ47E2afbj+02IB
B5NFHOjKQ1gJEz/9bVD31h7OBIiOjrjKy5JDGmuKKn+SeST64SxgE89bcpriBCeg
wbAzZ427D1yHss+K1BbnXi8+qqSxY//iZLGu2zQ/USF2b5spt9TRKt+HiCaWhXRW
hoWkmv+1ntkCuffjJ1oWrSRiqpbEsL3+dki+kN9/2Nvm99s/i2jRTg9X/jhs25Gz
sVgpyACJDAboBKxZH8BJbMb7cm1wG/KVfm831qnjOOTlXaUqLJ0Ghii56WeVzMgX
8gPU1WHVM6kGGkMZ9qQYibYk6x82y+vZNRoxs5o4jJ/x+yf8kmpFM3OnktbINdo=
=GY/m
-----END PGP SIGNATURE-----
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.
