Microsoft Fuzzing Botnet Finds 1,800 Office Bugs

CWmike writes "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 on Wednesday. Office developers found the bugs by running millions of 'fuzzing' tests, a practice employed by both software developers and security researchers, that searches for flaws by inserting data into file format parsers to see where programs fail by crashing. 'We found and fixed about 1,800 bugs in Office 2010's code,' said Tom Gallagher, senior security test lead with Microsoft's Trustworthy Computing group, who last week co-hosted a presentation on Microsoft's fuzzing efforts at the CanSecWest security conference. '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.'"

Comments

xkydgtufhlofhil

[Anonymous Coward]

ghulkgiplgbvihlnk luioguilgil.bjohj110-o; Huto;bn

Re:xkydgtufhlofhil

[sucker_muts]

don't understand this Score:4 Insightful comment. Can someone explain?

Even though your name does look quite suspicious, I'll try to explain anyway.

The parent is showing how fuzzing works:
Using random 'data' to test the various functions of software, so we can find out if a certain piece of input triggers undesirable behavior.

In this case you could say that he's not only giving an example, but is testing the slashdot user comments code as well.

But it's perhaps more an attempt at humor. :-)

Re:xkydgtufhlofhil

[jonadab]

Except that, in most cases, random letters in the ranges a-z and A-Z are not where you're going to find most of your problems. The major sources of bugs that can be uncovered by random data are assumptions that programmers (sometimes subconsciously) make about what the data are going to be like.

The most obvious of these are assumptions like "a newline can't occur in a single-line field" (a mistake web developers often make, because they assume the data are coming from an HTML input element that only allows single-line data; but an attacker can in fact send anything they want in an http request), or "nobody's going to have a single-quote character in their name" (hello, SQL injection attack). This sort of thing is probably not a major factor in Office, because it's common for documents to have those kinds of characters in them. There might be a couple of weird old control characters (like the ASCII NUL, 000), but those bugs were probably found aeons ago.

A second major category of problematic assumptions assumptions has to do with languages and code pages and character sets. When software that was written to assume a particular character set (like ASCII, or Latin-1) or even just one code page at a time (like, whichever one is the system default) has to be extended to support more (like, especially, Unicode), you run into all kinds of nasties. Again, though, Office probably had to deal with these issues a couple of versions ago. They may have found a few more, but at this point it's probably not the most fertile ground any more.

When you're dealing with file formats, however, there are also things like "the value at offset 0x003C from the beginning of the object header contains the size of the object, which can never be more than 0xFFFF" and "an object can embed another object by referencing it, but there are never any circular references, because the software doesn't allow the user to put an object inside itself". These sorts of assumptions pop up every time you write or change code that reads a file format, so they never go away really. This sort of thing is probably *most* of what the Office team found, I suspect.

Hey, Microsoft!

[geminidomino]

"We also want to fix things that are not security concerns."

It's 5AM EST. April Fools' day is over everywhere but a few pacific islands. Give it up already.

New bugs

[El_Muerte_TDS]

I wonder how many "new" bugs they'll create by fixing the found bugs.

Anyway, nice to see that they're performing fuzzing tests, not enough people/companies do that. There's also quite little tool support for it.

Re:"Botnet?"

[benjamindees]

They had to infect the computers with Office 2010.

Re:If only this was easier...

[owlstead]

As with all testing tools, the more of them you use, the better. There are many reasons why you don't want to employ all tests, e.g. lack of knowledge, lack of manpower, lack of money or lack of time. The good thing is that if you can get them automated, then they quickly become affordable.

For an example: I was thinking if it was wise to put findbugs (which works on compiled byte code) next to checkstyle (which works on source code level) in my Java project. Obviously I put them both in; they duplicate bugs but who cares ? I'll just look at checkstyle first and findbugs second. If I can put in a pre-build fuzzing component I probably will.

But fuzzing tools are different than unit tests. Fuzzing can never cover every nook and cranny. They will produce reports that are much less readable, and that cannot be directly tied to particular events (e.g. during regression testing). If anything, they'll put some pressure on developers to put in more unit tests; if the fuzzing tool finds many bugs in a component, it should be a good indicator that even the basic unit tests have not been created.