Thursday, April 1, 2010

Microsoft Runs Fuzzing Botnet, Finds 1,800 Office 2010 Bugs

Microsoft uncovered more than 1,800 bugs in Office 2010 by tapping into the unused computing horsepower of idling PCs, a company security engineer said today.

Office developers found the bugs by running millions of "fuzzing" tests, said Tom Gallagher, senior security test lead with Microsoft's Trustworthy Computing group.

"We found and fixed about 1,800 bugs in Office 2010's code," said Gallagher, who last week co-hosted a presentation on Microsoft's fuzzing efforts at the CanSecWest security conference in Vancouver, British Columbia. "While a large number, it's important to note that that doesn't mean we found 1,800 security issues. We also want to fix things that are not security concerns."

Gallagher declined to quantify the number of flaws found via fuzzing that qualified as vulnerabilities, saying only that the Office 2010 team did uncover security bugs in the process and patched them during development. Some of those vulnerabilities have already been addressed in older editions of Office, Gallagher added, because information obtained by fuzzing Office 2010 code was checked against the code in earlier versions -- such as Office 2007 and Office 2003 -- then patched during Office 2010's development.

Non-security bugs discovered in Office 2010 that also exist in previous editions will be fixed in those versions' upcoming service packs, Gallagher said.

Microsoft was able to find such a large number of bugs in Office 2010 by using not only machines in the company's labs, but also under-utilitized or idle PCs throughout the company. The concept isn't new: The Search for Extraterrestrial Intelligence (SETI@home) project may have been the first to popularize the practice, and remains the largest, but it's also been used to crunch numbers in medical research and to find the world's largest prime number.

"We call it a botnet for fuzzing," said Gallagher, referring to what Microsoft has formally dubbed Distributed Fuzzing Framework (DFF). The fuzzing network originated with work by David Conger, a software design engineer on the Access team.

Client software installed on systems throughout Microsoft's network automatically kicks in when the PCs are idle, such as on weekends, to run fuzzing tests "We would do millions of [fuzzing] iterations each weekend," Gallagher said -- up to 12 million in some cases.

The difference between Microsoft's old way of fuzzing -- which involved a tester setting up a fuzzer on a single machine, then letting it run for as long as a week -- and DFF was dramatic, said Gallagher. "We can do 12 million iterations without a lot of effort," he said. "Set it up, go home, come in on Monday, and we have the results listing all the issues. What used to take days now just takes an hour."