Microsoft Fuzzing Botnet Finds 1,800 Office Bugs 111
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.'"
Re:If only this was easier... (Score:5, Informative)
The whole point of the data is that it's unrealistic. There are a few tools out there for doing this type of testing, or easily modified to do it. I haven't used many testing tools but you could take something like Skipfish [google.com] and add in some fuzz testing pretty easily.
Re:xkydgtufhlofhil (Score:5, Informative)
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 (Score:3, Informative)
Fuzzing is a technique where you modify the data sent to a file, protocol or data parser (e.g. code that reads an xml file) by changing random bits. Thus, if you have a 'text' command, a fuzzer could change that to 'next', or if you have a quoted striing "test", the fuzzer could change the end quote to something else, e.g. ' "tests '.
Hence, what you can end up with is something that looks like random garbage.
Re:If only this was easier... (Score:3, Informative)
A fuzzer isn't really hard to write.
Pick a word-based variant of Dissociated Press [wikipedia.org] that requires similarity a random number of words back/ahead and allows split on special characters (separators) besides whitespaces. Feed it a lot of your actual files. Actually, the amount of data it can produce may be vastly bigger than the amount of data it takes in, because it can jump back and forth in the input files recombining their fragments multiple times.
Of course then you need a test unit that feeds the fuzz to your program.
Re:If only this was easier... (Score:1, Informative)
This is a great methodology of testing but to be honest I'm not sure it is within the scope of most software firms.
Microsoft runs huge (and I mean huge) server farms for all kinds of internal testing - unit tests for rolling builds, automated functional tests for the same, performance regression tests, compatibility tests (what if we run it on Vista without SP1 and with Office 2003 with latest updates installed?..) - you name it, it's there.
But, even with all the servers, it still takes hours for a complete test run.
Re:"Botnet?" (Score:3, Informative)
Odd that they would call it that publicly, given the negative connotation of the word. I would have called it "fuzzy clouds grid computing" or something like that.
Developers tend to name things that are used internally in a way that is short and more to the point, which is not necessarily something perfect for marketing/PR.
Sometimes these things slip through.
Re:xkydgtufhlofhil (Score:5, Informative)
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.
Re:xkydgtufhlofhil (Score:4, Informative)
Hey, I resemble that remark! And yes, it's resulted in chuckles over the years. Microsoft, DevelopMentor, random e-commerce sites... many have fallen to the Irish. When talking to security professionals, I introduce myself as "the woman whose name is a SQL injection attack", and it seems to help them remember me.