Microsoft’s Patch Tuesday announcement was bad enough, with six in-the-wild vulnerabilities patched, including one buried in the vestiges of Internet Explorer’s MSHTML web rendering code…
Like Mozilla, Google also lumps together other potential bugs it has found using generic bug-hunting techniques, listed as “Various fixes from internal audits, fuzzing and other initiatives.”
Fuzzing, in case you aren’t familiar with the concept, is an automated technique that probes for bugs by repeatedly confronting the software under test with input that has deliberately been modified to see whether the program chokes on it.
For example, a fuzzer might start with a known-good input file that you would expect to be processed correctly, without triggering any bugs, and progressively make a series of unusual or otherwise unlikely changes in the file, thus testing a program’s error-checking code much more broadly and deeply than hand-crafted files could manage.
Imagine that you had a compressed archive file, for instance, and you wanted to see how safely your decompression code would behave if the file were corrupted during a download, such as if a line-break character were accidentally inserted at some point.
With a fuzzer you could not only test for line-breaks at some points in the file, but at every possible point – and, better yet, you wouldn’t need to store all these slightly-modified input files for later, because you could automatically regenerate them on the fly every time you wanted to repeat the test.
Fuzzers may produce millions or even hundreds of millions of test inputs during a proving run, but only need to store the inputs that cause the program to misbehave, or more importantly to crash, so they can be used later on as time-saving starting points for human bug hunters.