I can't wait for the time when if your project reads files, fuzzing it is a well-known, recommended practice. (unless you're writing fully managed code)<p>There were some fuzzing projects before afl, but even with afl's recent popularity we're still in the situation where you just have to grab a random application, point afl at it and get some basic crashes in a few minutes. With clang-analyzer, coverity, afl, and many other projects available for free, there's no reason this should be possible.<p>Then again, I'm still waiting for the time when people don't code with sql injection issues...
Can someone explain why you would want to fuzz ffmpeg?<p>What's wrong with ffmpeg crashing when you feed it invalid input? What's the alternative to it not crashing? Should it continue transcoding or should it exit quietly?<p>What's the problem here trying to be solved?
afl [0] is awesome. I have it running right now. It found some of bugs in arachne-pnr [1].<p>I wish someone would do a JVM version (combined with the lines of QuickCheck and typed generators).<p>[0] <a href="http://lcamtuf.coredump.cx/afl/" rel="nofollow">http://lcamtuf.coredump.cx/afl/</a><p>[1] <a href="https://github.com/cseed/arachne-pnr" rel="nofollow">https://github.com/cseed/arachne-pnr</a>
Google has done a lot of work [1] with respect to fuzzing ffmpeg because it's included in Chrome.<p>[1] <a href="https://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html" rel="nofollow">https://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and...</a>
Very interesting and thought provoking. The article links to Google's page on finding 1000 bugs in FFmpeg (<a href="https://googleonlinesecurity.blogspot.co.uk/2014/01/ffmpeg-and-thousand-fixes.html" rel="nofollow">https://googleonlinesecurity.blogspot.co.uk/2014/01/ffmpeg-a...</a>).<p>This mentions the fixes they found (NULL pointer dereferences, Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, Out-of-bounds reads and writes to stack, heap and static-based arrays, Invalid free() calls, Double free() calls over the same pointer, Division errors, Assertion failures, Use of uninitialized memory.)<p>Some of those things could have been caught by static code analysis or stricter coding standards. Or, if it had been a C++ project you could replace some of those problems (NULL pointer dereferences) with using references in the first place instead of passing pointers around. That might be a bit of an oversimplification as it is a very complex project but for me it was a reminder to change my coding style in C++ instead of sticking with the C-style way of doing it.
No mention of security impact of these bugs in the tracker. Anyone know if FFmpeg has some vulnerability process, or do they just commit fixes and let other people worry about exploitability, security hotfixes and CVEs, like Linux?
I didn't see any note about what version these bugs were found in, or will be fixed in. For reference, at the time of this writing, my GNU/Linux box has ffmpeg 2.8.1.
OT: I can't describe how much I loathe "for fun and for profit" in titles - especially since the majority aren't linked to anything describing a monetary or resource gain. If you want to say something is useful, find a different way to say it!<p>I wish those titles had a weight to drag them off the front page much quicker.