Even though it’s posted on April 1st, this is actually *not* an April Fools prank.
It turns out that the Office team runs a “botnet” internally that’s dedicated to file fuzzing. Basically they have a tool that’s run on a bunch of machines that runs file fuzzing jobs in their spare time. This really isn’t a “botnet” in the strictest sense of the word, it’s more like SETI@home orother distributed computing efforts or but “botnet” is the word that the Office team uses when describing the effort.
For those that don’t know what fuzz testing is, it’s a remarkably effective technique that can be used to find bugs in file parsers. Basically you build a file with random content and you try to parse the file. Typically you start with a known good file and randomly change the contents of the file. If you iterate over that process many times, you will typically find dozens or hundreds of bugs. The SDL actually requires that every file parser be fuzz tested for a very large (hundreds of thousands) number of iterations.
The Windows team has an entire lab that is dedicated to nothing but fuzz testing. The testers author fuzz tests (using one of several fuzz testing frameworks) and they hand the tests to the fuzz test lab which actually runs the tests. This centralizes the fuzz testing effort and keeps teams from having to keep dozens of machines dedicated to fuzz testing. The Office team took a different tack on the effort – instead of dedicating an entire lab to fuzz testing they also dedicated the spare cycles of their machines. Very cool.
I’ve known about the Office teams effort for a while now (Tom Gallagher gave a talk about it at a recent BlueHat conference) but I didn’t know that the Office team had discussed it at CanSecWest until earlier today.
Nice piece of information. I did not know that windows team has a dedicated lab for fuzz testing. I am sure this will help immensely in security research. Keep it up!
Quite similar to what Condor does.
Fuzz-testing office documents usually only impacts the Office applications themselves (crashing Office usually doesn't crash Windows or other applications).
Fuzz-testing kernel-mode components results in bugchecked machines, which hampers developers ability to use the machine for other tasks.
Each method has its perks.