[FFmpeg-devel] [RFC] Fuzzer results and bugfixes

Michael Niedermayer michaelni
Sat Mar 6 02:19:45 CET 2010


On Fri, Mar 05, 2010 at 04:30:50PM -0800, Jason Garrett-Glaser wrote:
> All,
> 
> I wrote a rather simple fuzzer and started running it on ffmpeg using
> various input files.  I've found about 6 crashes so far (some appear
> to be possibly exploitable); I suspect to find a lot more as I try
> more types of input files.  Here's my tentative plan:
> 
> 1.  Start a roundup thread specifically for this fuzzer (only one bug
> report rather than a massive spam).

> 2.  Offer the same bugfix rewards as usual for fixing crashes reported
> in this thread by the fuzzer (duplicate crashes caused by the same bug
> are obviously not counted).

i wonder if security relevant bugs should have a higher bounty on them


> 3.  Because I have a very slow upload and most input files have
> multiple crashes, each sample will be only uploaded once: instead, the
> random seed used to generate the fuzz test failure will be posted.
> For example:
> 
> IronMan.mkv 140
> 
> means that IronMan.mkv, fuzzed with seed 140, caused a crash in decoding.
> 
> Using the fuzzer is trivial and much faster than waiting for my upload:
> 
> ./fuzzer input output seed
> 
> Is this a good idea?  I think it would be the most convenient for
> dealing with fuzzer-found crash bugs.  Furthermore, it would easily
> allow others to report new fuzzer-found crash bugs in a central
> location without scaring the crap out of everyone with hundreds of bug
> reports.

having hundread unrelated crashes in one roundup report seems quite difficult
to handle for people who try to fix any.
That is its quite hard to keep track of which are still in need of a fix
especially if one starts with
<list of 200 seeds crashing>
<list of 20 seeds fixed by X>
<list of 29 seeds fixed by Y>
<list of 3 seeds fixed by Z>
...

with that noone will know what is left

also the "just a single issue" renders roundups search capability useless

so i definitly would prefer 1 issue by independant looking (in terms of gdb
output) crash

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100306/9fbcadc4/attachment.pgp>



More information about the ffmpeg-devel mailing list