Acidus wrote:

When asked to clarify that statement, she acknowledged Microsoft won't classify the flaws as security problems. Rather, the behavior of Word 2007 is a feature, not a bug. "In fact, the behavior observed in Microsoft Word 2007 in this instance is a by-design behavior that improves security and stability by exiting Microsoft Word when it has run out of options to try and reliably display a malformed Word document," the spokeswoman said.

... [sigh]... [deep breath]... ITS F#@&ING INPUT VALIDATION! [Smack] WHERE's MY MONEY? [smack]

Your first problem is to continue rendering something you know is corrupted! Recovery is different from rendering. At first error, the program should stop rendering, shell the file out to a external recovery program which attempts to extract valid data structures and chunks. Any recovered data should be written to a new file and loaded into Word. Worst case is the recovery program crashes, in which case you don't lose Word.

She went on to suggest that it is no big deal if Word 2007 did crash under those circumstances, a scenario that could lead to the loss of any unsaved data. "The sample code in [Aharoni's] postings cause Microsoft Word to crash, and users can restart the application to resume normal operations."

And users can just reboot the box when a blue screen happens, so I guess thats not a DoS either. Jackass.

I'm really surprised the MSRC made an official statement that is to utterly retarded. One things for sure: Kymberlee Price wouldn't have tried to pull this crap. She respects the security community too much to try and keep a straight face when saying something as fucked up as "a crash isn't a DoS."

I think Frank Hayes of Computer World says it best:

If your application code is in control, it can gracefully reject bad input.

If your app code ISN'T in control, you crash. You're already owned.

This suicide-before-capture approach isn't "by-design" behavior. It's lack-of-design behavior.

And a "code guru" of any kind who thinks that's not a security and stability problem that needs fixing doesn't belong in this business.

And yet in programming classes in college you are not taught about delimiters or how to parse input so that invalid data doesn't make it through the system. I tried asking yesterday about how to make a program take anything that's not 0-9 (needs an int) out of the string before making it an int so it doesn't go psycho. The teacher responded that it's not something to worry about because he won't put an invalid response in the textbox. That's not the point though. Pretty much any assumptions about the quality of data input are bad, but teachers tell students they don't need to worry about that situation. Of course you need to worry about it. It may not matter on the specific program we had to write, but that is exactly the attitude that they should not be teaching. I suppose in upper level classes they will teach how to parse it, but by then, they've already taught us all that we don't need to worry about it because they won't type in the wrong stuff. Will a user in the real world type the wrong stuff? Probably. Typos happen. Will a hacker in the real world type the "wrong stuff"? Yes. If that wasn't true, where would SQL injections come from?