Code coverage to improve fuzzing results

Many fuzzers take a good file (template) as a starting point for creating malformed content. For years, dating back to Writing Secure Code in 2002, the SDL has encouraged people to fuzz their file parsers with a “good representative set” of template files. The question is “how do I tell if I have a good […]

Many fuzzers take a good file (template) as a starting point for creating malformed content. For years, dating back to Writing Secure Code in 2002, the SDL has encouraged people to fuzz their file parsers with a “good representative set” of template files. The question is “how do I tell if I have a good set?” At Microsoft, answer is code coverage, which’s in line with other external research (Guruswami, Miller, and Sutton, Greene and Amini to cite only a few). “Code coverage is only one approach to improving the fuzzing process. While it doesn’t guarantee that you’ll find all of the bugs in your product, it increases the probability that your fuzzer will reach the less frequently exercised parts of your code because you reduce the time spent exercising more common blocks of code. MSEC encourages software development teams to use this technique to maximize the efficacy of their fuzz testing.”

More info: Using code coverage to improve fuzzing results