fuzzing at scale

coderman coderman at gmail.com
Mon Jan 13 17:31:26 PST 2014


or, "keeping the 0day hopper full of candidates to weaponize"
 (you red or blue team? ;)


http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html
"""
FFmpeg and a thousand fixes
Friday, January 10, 2014 9:06 AM
Posted by Mateusz Jurczyk and Gynvael Coldwind, Information Security Engineers

At Google, security is a top priority - not only for our own products,
but across the entire Internet. That’s why members of the Google
Security Team and other Googlers frequently perform audits of software
and report the resulting findings to the respective vendors or
maintainers, as shown in the official “Vulnerabilities - Application
Security” list. We also try to employ the extensive computing power of
our data centers in order to solve some of the security challenges by
performing large-scale automated testing, commonly known as fuzzing.

One internal fuzzing effort we have been running continuously for the
past two years is the testing process of FFmpeg, a large
cross-platform solution to record, convert and stream audio and video
written in C. It is used in multiple applications and software
libraries such as Google Chrome, MPlayer, VLC or xine. We started
relatively small by making use of trivial mutation algorithms, some
500 cores and input media samples gathered from readily available
sources such as the samples.mplayerhq.hu sample base and FFmpeg FATE
regression testing suite. Later on, we grew to more complex and
effective mutation methods, 2000 cores and an input corpus supported
by sample files improving the overall code coverage.

Following more than two years of work, we are happy to announce that
the FFmpeg project has incorporated more than a thousand fixes to bugs
(including some security issues) that we have discovered in the
project so far:

$ git log | grep Jurczyk | grep -c Coldwind
1120

... we have carried out several dozen fuzzing iterations (each
typically resulting in less crashes than the previous ones) over the
last two years, identifying bugs of a number of different classes:

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.

We have simultaneously worked with the developers of Libav, an
independent fork of FFmpeg, in order to have both projects represent
an equal, high level of robustness and security posture. Today, Libav
is at 413 fixes and the library is slowly but surely catching up with
FFmpeg.
"""




More information about the cypherpunks mailing list