Slashdot Log In
Word 2007 Flaws Are Features, Not Bugs
Posted by
Zonk
on Fri Apr 13, 2007 02:43 PM
from the i-thought-that-was-just-a-programmer-joke dept.
from the i-thought-that-was-just-a-programmer-joke dept.
PetManimal writes "Mati Aharoni's discovery of three flaws in Word using a fuzzer (screenshots) has been discounted by Microsoft, which claims that the crashes and malformed Word documents are a feature of Word, not a bug. Microsoft's Security Response Center is also refusing to classify the flaws as security problems. According to Microsoft developer David LeBlanc, crashes aren't necessarily DoS situations: 'You may rightfully say that crashing is always bad, and having a server-class app background, I agree. Crashing means you made a mistake, bad programmer, no biscuit. However, crashing may be the lesser of the evils in many places. In the event that our apps crash, we have recovery mechanisms, ways to report the crash so we know what function had the problem, and so on. I really take issue with those who would characterize a client-side crash as a denial of service.' Computerworld's Frank Hayes responds to LeBlanc and questions Microsoft's logic.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
English-to-Microsoft dictionary (Score:5, Funny)
What's the matter? Did the Slashdot editors lose their English-to-Microsoft dictionary again?
I Wish (Score:5, Funny)
Taking a page from Apple... literally (Score:5, Interesting)
The old Apple ][ Reference Manual included a few pages of technical terms, with definitions. Buried among entries like track, sector, stack, and interrupt was this gem:
feature n. A bug, as described by the marketing department.
Parent
Re:Taking a page from Apple... literally (Score:5, Funny)
My sad realization about that definition is that I just looked it up to see if you were serious. You were. Perhaps an even sadder realization is that I was able to reach up to the shelf above my desk and instantly grab a copy of the Apple ][ Reference Manual---right between The TeXbook and an Imagewriter II owner's manual that I used to use as an ASCII table reference before the rise of Google or asciitable.com.
Sigh. I am, indeed, a geek. I suppose there's no escaping it.
Parent
Let me see... (Score:4, Insightful)
I hate to say it, but I'm going to have to come down on Microsoft's side on this one. If it's a non-exploitable crash, then it's a simple bug in handling corrupt documents and nothing more. The researcher can ring everyone again once an exploit has been found.
As for the DoS potential... seriously, why is everything a "Denial of Service" with these guys? It's a bad document. Word crashes. Life goes on. It's not like your computer is going to become unusable because Word crashed. You get minorly inconvenienced by the jerk who sent you the document, you figure out that the doc is bad, then you move on.
Re:Let me see... (Score:5, Insightful)
If the facts are as you've described, I agree that there isn't a security issue here. There is, however, still a bug. Anytime a program crashes for reasons other than hardware failure, there is a bug. If it takes really unusual input to do it and there are no security consequences, it may be a minor bug, but it is still a bug.
Parent
Re:Let me see... (Score:5, Insightful)
By definition, the app crashing is a denial of service. It's no different than sending a Christmas tree packet to an ancient unpatched router: it goes boom, shuts down the network, no network service. Word crashes: boom, document maybe lost, no use of Word.
A program must be able to recognize invalid input and take appropriate action. Allowing (or forcing) a crash is NOT acceptable.
Parent
Re:Let me see... (Score:5, Interesting)
-matthew
Parent
Re:Let me see... (Score:5, Interesting)
The Open BSD guys have a philosophy: "The only difference between a bug and a vulnerability is the intelligence of the attacker."
I wish more programmers held this view! A bug is an undefined state of the program. It's quite clear that this is a dangerous position for your program to be in. Bug really are baby vulnerabilities. It's best to remove them as soon as you find them.
Simon
Parent
Re:Let me see... (Score:5, Interesting)
However using bad documents to crash Word is still a flaw in Word, in my opinion. The application should just say "Can't open bad/corrupted document" and let the user keep working. In the blog he says: I understand the rationale, but I would argue it's rather sloppy programming that uses a crash as a means to prevent such bad things from happening. Exceptions can be thrown, but they should be caught and used to halt the "bad actions", and revert back to a normal program state.
Obviously it is better to crash than to execute arbitrary enemy code. However it's better still to just refuse to execute arbitrary code, but otherwise keep running. The problem with using crashing as a security system is that then the "bad guys" will try to crash your application on purpose (calling it a DoS is a stretch, mind you), which opens up new security problems. (A crashing app may expose other security vulnerabilities, disclose otherwise protected information, destabilize other apps/the OS, etc.)
Parent
RTFA - not just Word crashing (Score:5, Informative)
Actually, according to the Computerworld article, two of the bugs discovered will peg the processor at 100 percent, forcing a cold reboot that potentially will do a lot more damage than just corrupting your Word documents. Whatever your philosophy otherwise, that really is a denial of service.
Parent
Re:Let me see... (Score:5, Informative)
Sorry, I don't buy it. The only way that is a valid expectation is if you explicitly tell it to crash when it gets malformed data, which is offensive and stupid. The proper thing to do is to tell it to alert the user if there is malformed data, and then clean up and get ready to parse another document.
Crashing is definitely a sign that something bad is happening. Traditionally, when an app crashes because of an invalid document, it's writing to some memory it shouldn't be. This is a sign of lazy or stupid programmers not doing proper checking of the input.
Parent
Better recovery... (Score:4, Insightful)
I am fully aware that writing bug-free software is impossible. Ultimately, it is unavoidable that crashes will occur. When they do occur, they should be handled as gracefully as possible. However one should not defend one's code (and coding flaws) by saying that "sure it crashes--but the crashes are part of our carefully engineered recovery mechanism!" That's a lame excuse, because if you're aware of a consistent crash condition, you should be able to code so that instead of crashing, the program does something more friendly.
He's got half a point (Score:4, Interesting)
Wouldn't it be a good idea to shut down the app to prevent your whole network getting hosed? And doesn't the pain-in-the-assitude for the user maybe prevent them from opening shady docs the next time around?
Admittedly, it would be best if the flaw never existed in the first place. But if fixing the flaw outright is out of the question, why isn't this a good solution?
But seriously.... (Score:4, Insightful)
I can see Mr. LeBlanc's point, that it's better to crash than open up your system, but it seems like they are taking this awfully lightheartedly. They're still bugs and they still need fixed. I think they are confusing debug features with release features.
explosive code? (Score:5, Insightful)
From the linked blog...
1) Your code blew up, and you're about to get 0wn3d. Yup, it's exploitable, and the customers are not going to be happy.
2) Your code blew up, and maybe it is exploitable, maybe not.
3) Your code blew up, and you meant it to blow up, and it's clearly not exploitable.
Since you are not coding specifically for your application to crash (Or I hope not) surely there can be no 3. 2 is as good as it gets, you have done everything you can to prevent your code "blowing up" you have tried to handle anything that can be thrown at it gracefully, and you have done everything to ensure that when if and when things do go wrong they can do no damage, that's 2, not 3. If you cannot foresee and prevent every possible thing that could cause your application to crash (which you can't), then how can you foresee every possible way in which that unforeseeable crash could be exploited. All you can ever do is your best.
Next up, from the article:
Two of the three bugs result in a denial-of-service-like situation, with the PC's processor maxed out at 100%, making the machine unusable until it's rebooted. The third, Aharoni suggested, could be used to introduce remote attack code after an exploit causes an overflow of "wwlib.dll," a crucial Word library. But "code execution is not trivial," he added.
If described correctly then these bugs all pose a risk. sure the first two are minor risks, the later is major, but all three are bugs that should be listed as security vulnerabilities. I would suggest that the reason that they are currently not being seen as such by Microsoft, is simply that no one can be sure if the conditions required to trigger them could be utilised by anyone wishing to take advantage of them, and thus they are theoretically less threatening than many of the other issues that have plagued Microsoft Applications in the past.
In the end however we should be simply sating that a problem exists, it may be a security risk, and until it is fixed, we will treat it as such. Anything else (rightly or wrongly) simply smells like someone is covering up issues, and lets be frank, Microsoft doesn't have enough good will for that to be acceptable.
Re:Let's just get this out of the way then... (Score:5, Informative)
"a tool that probes an application for vulnerabilities by sending random input"
This is known as an appositive phrase.
Parent
Re:Let's just get this out of the way then... (Score:5, Funny)
Um, read that again, and see if you can find the problem.
Parent
Re:Let's just get this out of the way then... (Score:4, Insightful)
I found two:
1. No one reads TFA
2. There are plurality of TFAs
"Um, read that again, and see if you can find the problems.
There may be a plurality of errors in your statement, not sure
*head explodes
Parent
Re:Let's just get this out of the way then... (Score:4, Funny)
Parent
But, But... (Score:5, Funny)
OK, gotcha, but how do you differentiate this from normal Windows behavior?
Parent
Re:But, But... (Score:5, Funny)
Parent
Re:I didn't know that (Score:5, Insightful)
Parent
Re:Input validation (Score:5, Insightful)
If Word went ahead and executed arbitrary code, that's one thing. But as it stands, it just crashes out.
You do understand that in many cases, a "crash" is when the software attempted to execute random garbage; and that if you tailored the garbage, you would have an arbitrary code execution vulnerability?
A crash, frankly, is very often an incompletely exploited code execution vulnerability. That may not be so, here; but if the crash is caused by stack or heap corruption, there's a distinct chance the triggering dataset could be made into a shellcode exploit or the like.
Parent
Re:I don't see the problem (Score:5, Interesting)
Apparently that specific line of text exploits the way that notepad determines whether the file is encoded in ASCII or Unicode.
Parent