Slashdot Mirror
Word 2007 Flaws Are Features, Not Bugs
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.'"
What's the matter? Did the Slashdot editors lose their English-to-Microsoft dictionary again?
Um, it's defined in the twelve words after "fuzzer" in TFA
"a tool that probes an application for vulnerabilities by sending random input"
This is known as an appositive phrase.
My turnips listen for the soft cry of your love
http://en.wikipedia.org/wiki/Fuzzer
Windows is filled with these nice features too. Microsoft is sure to include them in every piece of software they release.
Why spend on testing, when you got paying consumers to do the bug reports for you?
It may be unethical, but they ARE getting richer by the minute.
From wiki:
"Fuzz testing or fuzzing is a software testing technique that provides random data ("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing built-in code assertions), the defects can be noted."
Respect the laws of physics, for the laws of physics have no respect for you.
I wish I could just pass out when my wife asks me some stupid question that I don't want to answer. Better yet, when I'm asked to fix a bug at work, it would be nice to just roll over and hit the snooze. Let's apply this everywhere.
"Please, shut up. Just when I think you can't say anything more stupid, you speak again." -Archie Bunker.
...if I understand this correctly. Basically, a security researcher believes he's found a buffer overflow. However, he has not yet found a way to exploit that overflow because Word keeps crashing. Microsoft says that the crash is preventing any security hazard, and therefore there is none. Correct?
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.
Javascript + Nintendo DSi = DSiCade
The spokesthing actually contends that the crashes are "a by-design behavior that improves security and stability"
My turnips listen for the soft cry of your love
That could be considered a flaw of word as well. It's more complicated than a text editor should be.
0xB315AA8D852DCD3F3DCA578FD2E0BF88
I'm going to go ahead and say that it's not necessarily a "security risk" as it is lazy coding. The majority of us here know the importance of input validation; just because the file ends in .DOC doesn't make it a bona-fide, working Word document.
If Word went ahead and executed arbitrary code, that's one thing. But as it stands, it just crashes out. Elegant? Not by a long shot. Security risk? Not so much.
Sony ha
It seems to be a typical response from Microsoft.
Another example I came across recently is here. What's the point of designing as such?
DoS (Denial of Service), not DDoS (Distributed Denial of Service). There is no "distributed" in crashing these desktop apps.
Javascript + Nintendo DSi = DSiCade
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.
Say you have a known vulnerability in your code, which fixing would require rebuilding your app from scratch (or damn near close enough to make it too expensive to fix). Also say that you have the capability to detect an attempt to take advantage of the flaw before any damage is done, and that shutting down the app will prevent further damage.
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?
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
Um, it's defined...in TFA
;-)
Um, read that again, and see if you can find the problem.
there you go, expecting a slashdotter to rtfa. Shame on you...
Damn. I thought the whole Word app was a giant bug. Turns out it is a feature that they can charge a lot of money for. It was confusing me since it only seemed useful if you wanted to butcher a document.
"Um, read that again, and see if you can find the problem. ;-)"
...which means there's an error in your statement, which should read ;-)"
...
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
My turnips listen for the soft cry of your love
Would any bright egg here care to explain what the hell an 'appositive phrase' is?
Yes I could google it, but so will 100,000 other slashdotters, so let's just post the answer here and be done with it.
Ok so 2 of the 3 bugs result in a DoS type situation and the third could allow for execution of arbitrary code... Using a Fuzzer dont you typically find DoS/Reboot/Crashes first and then more research to include debugging can show where in memory the crash occurs and then you move into the world of tailoring an overflow and allowing for execution of arbitrary code...
To me DoS'ing a client-side app like Word is an annoyance, but I would expect to see exploit code coming that does do code execution or privilege escalation of some sort and then MS will patch it on Tuesday just like they've been doing for years...
News Reporters Make Tasty Polar Bear Treats!
Unless you distribute a Word document exploiting the bug by email, for instance.
After all, I am strangely colored.
OK, gotcha, but how do you differentiate this from normal Windows behavior?
Faster! Faster! Faster would be better!
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.
Almost all the programs crash on invalid input, even Firefox and OpenOffice. So, hate to say it, MSFT is right in claiming that it is better to crash than to give a command line shell. But so many of the MSFT buffer overrun problems start out as crashes and people keep probing and probing and bingo, it becomes a remote code execution flaw. I thing the Windows Meta File graphics handling bug was a low priority crash bug for a long time before it became a remote code execution vulnerability. So while porturing it as "not a bug", hope they quietly work in the background and fix the issue.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Microsoft declared that they are not crashes at all; they are "rest breaks".
Chris mattern
I guess it is an attitude problem.
:)
If they said their software is sold "as it is" and that it possibibly had problems and were humble enough to admit it, there would be fewer MS-haters out there.
I agree with you on the impossibility of completly testing a software of the complexity of Word. No argument there.
BTW, calc.exe already GPFed on me.
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.
Breakfast served all day!
How does saying "light" when you meant "like" make you feel?
Me, I feel like having another beer.
The bigotry of the nonbeliever is for me nearly as funny as the bigotry of the believer. - Albert Einstein
I'm not 100% certain, but I'm pretty sure that my programming professors would have given me an F if as part of input validation I had put:
// this is to prevent abusing an exploit Prof. X... no really...
... so how is it that Microsoft (or anyone else) thinks they can argue that this is intended? Does it stop the exploit from being used? Possibly, but that does not mean that they should get to shrug this off as "not an issue". There -has- to be a more elegant way to handle it.
if (isExploit){
crashApplication();}
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
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.
Breakfast served all day!
1) It's too much effort to read the article.
2) It's um... Can you repeat this one, I didn't read it.
Meh, it's only Word. Firefox goes down in flames every now and then, but it recovers at the spot it left off so no big deal. I guess the same thing is happening with Word. Annoying but no big deal.
If you want a 'big deal' you should check out Words (XP and downwards) file handling bug. Now _that's_ brain-dead. Basically, every time you use the undo function Word opens a new file handler. Keep at it and the OS eventually runs out (especially a problem on the Mac) and you can't save your document or open any files.
Oh, and what was MS's excuse for not fixing this bug sooner? The idiotic teck complained that his debugger crashed because it opened too many handles, so he couldn't fine the bug. Well DUH!
You REALLY must be new here if you expect anyone on /. to come up with new and original arguments for why Microsoft sucks.
"Oh drat these computers, they're so naughty and so complex. I could pinch them."
Marvin the Martian
a phrase that is placed in apposition to a noun or another phrase, usually serving to clarify the meaning or intent.
an appositional phrase, a phrase that clarifies meaning, is a fancy way of saying "redundant"
... before Microsoft started getting all their ideas from me, instead of the other way 'round:
http://www.ubersoft.net/d/20030224.html
but more specifically
http://www.ubersoft.net/d/20030228.html
Eviscerati.Org: All Hail the Eviscerati
I don't know how exactly the bug came above, but don't you think that inputting any UTF-8 text into Word shouldn't crash the system? Ok, I can agree that you don't want to accept bad data, but just reject it then. I mean, Word 2007 is now based on XML (or so they say). If the XML is wrong, it would be simple to detect that using an XML parser, which you could perfect and use for several applications. It's not THAT difficult to create a good set of XML/data parsers which gives you the status OK or NOT OK and then allows it to go into the system.
In software programming, just as much as in web programming, there is a saying: never trust the input, no matter where (you think) it comes from.
If it crashes in any other way (overwriting memory, input through plugins like SOAP or so) the same is true, it is Bad Programming (c) because you either didn't check the input, or didn't protect your share of memory.
Custom electronics and digital signage for your business: www.evcircuits.com
I think your sort of crash is an intentional abort.
There's a BIG difference between an application writing junk to memory and crashing somewhere in malloc because things are completely hosed, and an application deciding data makes no sense and orderly aborting the operation.
Your program seems to do the second one, which is good. It's perfectly appropiate for the program to quit if it's for example a commandline program for batch processing. Were it a GUI program you'd stop processing, produce an error, and let the user retry or whatever. You could do that because your program is still working and in a sane state.
The Word crash isn't that, the application fails completely with an access violation. If you were running it under an IDE you'd be looking at the debugger and a stack trace. MS Word couldn't continue in this situation because at this point the state is corrupt -- there's no hope of recovering from it.
Apparently that specific line of text exploits the way that notepad determines whether the file is encoded in ASCII or Unicode.
Actually, in my opinion he's right.
People act as if a crash is the worst thing in the world. Generations of programmers have been trained to think of a crash bug as the ultimate badge of shame. The problem is that it is not, by far, the ultimate mistake.
I think it's useful to keep this in perspective. It's better that you crash the user's car than run over the user's baby. I always tell guys who work for to to place bugs in the following order of severity (1 is highest severity):
1) user's system security is compromised.
2) user's data is corrupted or lost.
3) give wrong answers that aren't obvious (2 and three might be interchanged in some circumstances)
4) crash bugs and obvious garbage output
It's not that crash bugs are good. It's that given a choice between a crash and things higher on the list, you ought to choose the crash.
This is not a choice that, once upon a time, we had to make. Crashes happen when a condition you hadn't anticipated happen, so they were not (as a rule) a matter of choice.
Java checked exceptions changed that, and required that I develop clear priorities. For non-programmers, an exception is a condition (usually abnormal) that can occur some place in your program. A checked exception is one that it is mandatory to handle some place in your program, otherwise your program is not valid.
I'm not religiously against checked exceptions, other than that they're a bad choice for default. The problem is that the places where exceptions occur are often not the right place to handle them. The temptation is to mishandle the exception, particularly exceptions that are rare, at a low level. Sometimes this is a temporary measure so you can get to some initial tests you want to do, and you never get back to undoing it. Sometimes it happens because the programmer doesn't know a good way to handle the exception, so he papers it over.
The result is that you convert a crash bug into some other kind of bug. Often a bug that's higher on the severity list. That's why converting a checked exception into a non-checked exception is often the best course of action, even though it creates a possible crash condition later on.
Automated testing does, or potentially can, stand in for the function of checked exceptions with less risk. Some kind of annotation that was integrated with unit testing might be ideal.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
According to the article, the crash in question is a result of Word using the SafeIntOnOverflow() function to deal with integer-overflow. That function throws an exception on integer overflow. That the function is being used in the code is evidence that the code is indeed checking the validity of an integer. But apparently there's no good way to recover from that situation, so they don't bother to catch the thrown exception and let it crash. Seems good to me. The only reason there was integer-overflow in the first place is that some researcher was running the app in a debugger and feeding it random data.
Now, someone could intentionally create a corrupt document that causes integer-overflow, which would cause the exception and crash, but real documents won't cause that behavior (notwithstanding other possible bugs).
-- "I never gave these stories much credence." - HAL 9000
"Error: the operation completed successfully"
I kid you not! This was common in Win98 and observed also in Win2k - if an app crashed, causing DrWatson to pop up and offer to save some kind of crash log, just click the save as button, and then cancel the save. Voila.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Wow. I thought this was a joke; but I just tried this on Windows XP, and it really happens as the poster describes.
"If you understand computers, you know that a computer normally is immune to the character of the data it processes," he wrote in the June U.S. Naval Institute's Proceedings Magazine. "Your $2.95 calculator, for example, gives you a zero when you try to divide a number by zero, and does not stop executing the next set of instructions. It seems that the computers on the Yorktown were not designed to tolerate such a simple failure."
Microsoft running a warship? What could possibly go wrong? Oh yeah - absolutely everything, since Microsoft can't be bothered to sanity check input.
FYI, Microsoft screwed up here and it's difficult to defend them in this instance without coming off as a dunce yourself.
Actually, I can think of two new features it's gotten since Windows for Workgroups:
1. The ability to open files larger than 64KB... I'm not kidding, try it.
2. The ability to save and display files in UTF-8 and UCS-2/UTF-16.
A bug in the API that the latter uses is actually part of the problem the grandparent mentioned.
Of course, no one should use Notepad for doing anything useful... As a program, it does even less than its predecessor, MS-DOS's Edit.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Hahahaha!
That is so early 90's!
Hello?? We have the internet!
Software can be downloaded!
In Windows, I can't just type in "office", click the resulting "kde office" and "open office" programs, and have them automatically downloaded for me, without fuel being burnt to get the bits from there to my computer. Amazing!
Also, I can just type in almost anything I may want my computer to do - and behold, one of more than 10,000 programs shows up which can be installed with a single click!
Oh wait, there's more. When I play a movie in full-screen, a bunch of "Would you like to update me?" dialogs of various programs don't jump up at me!
In fact, *all* (and that means all software you have) updating is done from a central location - by clicking the update icon.
Oh, Windows doesn't have that? Pitty, maybe I should stick to Linux!
While perhaps producing some rather amusing results, this is a unfortunate but unavoidable consequence of Notepad having to support a variety of encodings of text files.
It's not really news though, and I doubt Hugh Thompson deserves any credit, Raymond Chen explained why things behave like this back in 2004.