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.