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.'"
And what about the document you were working on?
...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
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
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.
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.
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
Sony ha
WAD is my most favored TLA for such responses, with a parenthetical 4 letter variant WA(P)D. Respectively Working As Designed and Working As (Poorly) Designed.
Odds are with this particular component, they were on the way to reducing functionality in their core component to force you into buying a third party developed component that was actually well designed and or useful.
Unless you distribute a Word document exploiting the bug by email, for instance.
After all, I am strangely colored.
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
It's a fine solution. But call a spade a spade and say:
"Sorry guys, but we're leaving this bug open for now because it's too hard to fix it securely."
Do not come up with lies like:
"This is a well-designed application and even those crashes you experience are an intentional part of our security design."
Has anyone seen the Spongebob episode where he keeps everyone laughing by ripping his pants on purpose?
(Think about it, it's not offtopic.)
according to this guy, you train a programmer as if it were a dog. You punish it by yanking on the leash, when they make too many bugs. You reward it by giving it a biscut when it does something good, like write an amazing piece of software with crappy design documents as input.
Do managers really think this way ? Are we looked upon as professionals ? Or merely some kind of, easily trained, excitable, bark at the mailman, get lonely when the master leaves us alone and doesn't play fetch with us, peculiar species of mammal ?
I can throw as many stones as I wish; my house is made of transparent aluminum.
Come on mods. Funny? Yes! Insightful? Not even close.
We all get it--Linux is better; Windows is for Losers; OSX is pretty but someone else with money can buy it.
Many people use Windows daily without the problems that caused you such trauma that you continue to rant about it daily. Get over it.
Don't like Windows for idealogical reasons? Fine.
Don't like it from a security standpoint? Fine.
Don't like it because it looks ugly and stole your candy? Fine.
But it's impossible to take you seriously when you employ the *same tactics* of FUD that you like to claim every single time Microsoft says anything.
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.
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
Microsoft never said it's a feature or denied it's a bug. Their only contention is that it's not a security risk, and they back that up pretty well. Please stop diluting the force of my well-targeted anti-Microsoft rants with these mindless assaults on straw men.
I'm awake! The answer is BONK!
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.
No, he doesn't have half a point. Because:
1) If the spokedroid said "we have a bad bug there, and fixing it will be too costly because it will slow the opening of well-formed document, so we implemented the emergency exit as a workaround before we can provied a real fix", then he may have half a point. But this is NOT what he said.
2) Furthermore, if they can detect the issue when it occurs, then can exit nicely (putting a MsgBox, then exiting). Because, if they don't tell the user that the document he opened caused the crash, then the user will try again
3) In any case it is a bug, and cannot be turned into a feature by the spokedroid, or the ActiveApologists
Anyway, when the most powerful development shop on the planet, owned by the richest guy in the world pretend that a crash in the most used application ever is not important, then, there is something rotten in computer science.
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!
I'd apologize for the rant but this kind of bullshit spouted by slack ass "Programmers" and "Developers" just pisses me off to no end. Keep thinking your gonna have that job security you always wanted by making sure there's no one else that can weed threw your garbled mesh of spaghetti, when in reality making software that actually works if far more job securing. But then again I would probably be out of work if the "developers" of the world actually did their shit right since organizations would need people like me to clean it all up.
Fuck the karma, some one had to finally clear this up, too bad no one in a position to actually change things will read this.
If you are looking for a "silver bullet" to all the woes of software development you are not going to find it, just like the architects and physical engineers of the world have never found one in their fields. But what Engineers have found is that building something right the first time is the most effective (a.k.a. cheapest) way to build. It may be sad but if we started allowing users and clients to sue for bugs in software you would see software become more stable and bug free fast. Yes it does take a lot of resources to build something that will last the test of time, but it's far more effective than rebuilding it for eternity (could you image trying to keep the Great Pyraminds standing had they been built from cheap materials like card board, or should I say papyrus board).