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?
Would any bright egg here care to explain what the hell a 'fuzzer' 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.
FATMOUSE + YOU = FATMOUSE
The fact is, you can probably DDoS just about anything more complex than a text editor.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
And what about the document you were working on?
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.
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
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?
War is peace.
Freedom is slavery.
Ignorance is strength.
Crashing means you made a mistake, bad programmer, no biscuit.
... Great attitude pal, keep it up.
So if your application crashes, this is my mistake as the user?
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.
If one's idea of a Feature is something that makes money for the seller of the software, that's one thing. If a Feature is something the buyer wants, or thinks is being paid for, then this is something else, for which coarse language becomes more descriptive.
Umm RTFM, I mean article
Would any bright egg here care to explain what the hell a 'fuzzer' is?
For those who didn't read the article and want to know what a fuzzer is;
"Aharoni said he found the flaws using a "fuzzer," a tool that probes an application for vulnerabilities by sending random input"
Snipped from the article.
Somehow clipping a line from the article doesn't make me feel light a bright egg.
The truth shall set you free!
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.
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!
Now, take the same file (or entire working folder), copy it to a local drive, and it edits and saves just fine. I haven't figured it out yet, probably never will. Luckily every time this has happened to me it's been a group project file and I regularly give my group members backup copies for their own edits, etc.
Arguing with an engineer is like wrestling a pig in mud. Soon, you realize the pig is dirty, and he likes it.
The operation completed successfully.
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.
I hated when they used the term DOS for the Mozilla crashes, I hate when the use it for Microsoft desktop applications. Just say you found a way to crash the program. Woo hoo! It doesn't sound as serious as DOS, but it is more accurate. Leave DOS for server attacks that clog a network, or prevent a server from being accessed. But entering in Chinese unicode characters into a shareware text editor that causes it to crash is not a DOS attack. PUH-lease!
Some settling may occur during posting.
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
Ignorance breaks the symmetry of your argument, It should be :
Ignorance is knowledge
Well.. maybe. Or Maybe not. But Definitely not sort of.
It's not actually that unreasonable. In my code I do my best to detect invalid input and fail gracefully if possible, but if there's something I haven't thought of I have checks deeper inside that end up cleanly crashing the program if something really unexpected occurs. The fact that it gets past the first checks, and has to crash, is a bug. The fact that it crashes may very well be designed behavior, though, and far better than the alternative.
Of course, their public statement is stupid. What they should be saying is "yes, you have found a bug, the crash is a safe error handling system designed to prevent any security holes, there is nothing to worry about with this bug besides annoyance but we're working on a patch."
Breaking Into the Industry - A development log about starting a game studio.
WAAAHHH !!! I LIVE FOR BISCUTS!!! Doesn't he know that biscut's are a programmers lifeblood and he will wither and die without a steady supply !
I can throw as many stones as I wish; my house is made of transparent aluminum.
Has anyone seen the Spongebob episode where he keeps everyone laughing by ripping his pants on purpose?
(Think about it, it's not offtopic.)
Microsoft declared that they are not crashes at all; they are "rest breaks".
Chris mattern
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.
Where a high (100%) level of consistency is absolutely required.
.log file) is a feature in itself.
Basically, the default behavior on any exception is to crash, and roll back any open transactions. There's just no way to recover from something unexpected, and still be able to guarantee that the next commit to the DB isn't going to fuck something up.
I have described this behaviour as intentional, and have played it off as a feature - directly comparing it to a competitors product, which took an "ignore error, keep on truckin'" approach. They fired the first shot by finding a bug that made our app crash, and claimed the crashing meant it was buggy. Meanwhile, no crashes on their side means no bugs.
So I showed how I could exploit a bug to start corrupting records, and even found a way to do it willfully (ie; change your parking ticket into a warrant for forced sodomy).
Of course, we treat every crash as a bug - but the fact that it crashes (after writing out as much relevant info as possible into a
I don't need no instructions to know how to rock!!!!
Seriously, the recovery system they are mentioning is good.... FOR TESTING! Real software shouldn't crash, if it does crash it better be because of hardware failure because software shouldn't do so much that crashing is an option. That's theory of course but it's a possible and working theory in most cases.
Buffer overflows? Create and use a SAFE version of functions... Like.. I don't know? Try snprintf with only the output buffer's size?
Buffer overflows are the fault of the programmer and there should be no excuse. Telling the system to crash instead of overflowing is a fix, but it's neither a good fix or a feature. It's a BUG that has been paved over by paper. Until you come back with concrete it's not really fixed.
Let's switch it around. If my game company submits a game to the Microsoft certification process which crashes, and we gave this excuse we'd be rejected in 2 seconds. Why is in-house Microsoft products gets a pass on this matter?
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.
Did a dotcom refugee work on Word?
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.
Traditionally security is defined as the AIC triad (Availability, Integrity, Confidentiality), any issue that violates one of these is classed as a security issue (i.e. I can bypass passwords, modify information in the system or make the system unavailable to legitimate users). In general crashes are considered a denial of service, and more importantly to me say that the code is behaving in an unexpected way. Had it been expected that processing a malformed file would be a problem the application should do something like "I'm sorry, this file appears malformed, I can try repairing it, but if that doesn't work then you can basically kiss the data goodbye, sorry about that" to the user. In this case the application crashes. Based on previous results, with exploitable Word (and Excel, etc.) flaws that allowed for code execution I'm going to go out on a limb and put my money in the corner with "these flaws are exploitable, it just hasn't been figured out how yet."
So this play on words is why they say Vista is more secure.....
Crashes less! More secure!
According to their logic, and unlike "Tastes Great! Less filling!", it can't be both!
mod me funny
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!
While not every crash is exploitable, usually the crash means that you can corrupt memory.
The trick is being able to control HOW you corrupt memory. If you can do that to a sufficient degree, you can 0wn someone's computer. It's NOT always obvious whether or not an overflow is exploitable. More than once, someone has said "this isn't exploitable" because they didn't fully understand the bug, only to have someone who knows it better corrupt the memory just so, and turn a crash into an exploit.
Also, even DoS isn't a good thing, as you might know if you'd ever been under attack. Yes, it's hard, sometimes incredibly hard, to protect yourself. But unless you do, you can expect to be kicked offline any time some wanker goes after you. And if you think it doesn't happen, you're kidding yourself. I've seen security websites be attacked by "l33t d00dz" who hated them, I've seen Christian sites flooded by those who hate them, I've seen total wankers attack people for no damn reason at all. I'd tell you to check out Attrition.org's defacement mirror, but they took that down a long time ago. There are just as many, if not more, DoS attacks than defacements, you know.
So no, I won't go along with you and say that crashing "prevents" a security hazard. If you can't use your computer, what does it matter if the reason you can't is because it's crashing or because you're 0wn3d?
That's Microsoft PR talking, not anybody with a damn clue.
IIRC wasn't one of the UNIX design philosophies that if an application becomes unstable it should crash as quickly as possible and create as much noise and debugging output in the process(or something along those lines)? So going by that it would seem the MS Offices is doing the right thing and IS crashing and generating plenty of errors and debugging info in the process.
I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
I dont have time to log in but I have to point out that the biggest flaw in Office 07 is the office menu, when single clicked it drops a menu, when double clicked it kills the app...fucking redmond retards!
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 could not believe my eyes when I read this ridiculous statement by Microsoft. Do they want to tell us that Microsoft designed these crashes deliberately? The only assumption I can make is that it is a standard function of Word 2007 to crash. It is enough to make you laugh out loud when you read unbelievable, incomprehensible statements like this.
www.cybertopcops.com
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
it would appear that Microsoft doesn't consider anything to be a security risk unless it's 0wn3d Bill Gates' personal machine.
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!
Look. When "something" behaves in a way it's not supposed to behave, then it's a problem. Stating that a crash is the lesser of alternative evils is insane spin.
I "grew up" in a computing environment that did not involve mainframe style computing. Everything was on smaller, personal class machines. "Reboot" was considered a solution to a problem. I recall the first time I ever stated that "reboot" is part of any diagnostic procedure in front of a former boss. He cringed noticably because he grew up in a mainframe environment and "reboot" was a very major and extreme thing to do.
I took that perspective to heart and since then, I have focused my attentions and enthusiasms on solutions and products that do not involve rebooting and crashing. Is it any surprise that I'm not a Microsoft-Solution guy? The Microsoft culture is plainly that rebooting is okay and natural and that it's just accepted as normal even when it has impact on business process, efficiency and productivity.
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!
The people who buy Word must find it acceptable enough to put money down for it. Unless your trying to argue that software crashes is a new concept to people.
Whether people not in those two groups find it acceptable is irrelevent to my point.
When I read the article, it sounded to me like two of the bugs caused the entire PC to hang, and required a complete reboot of the system. Not, as it seems to be assumed throughout these responses, just Word. It doesn't say in the article that you could just kill the offending word process. It says you have to reboot the machine. That is absolutely a DoS. "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."
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!
... 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
Otherwise he's going to get dizzy and fall down.
Crashing is damn sure a way to provide a DoS. The Computerworld guy is absolutely right - just display an error dialog. Geesh, can't these guys admit a mistake?
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
Microsoft developer David LeBlanc is exactly what I would describe a well educated brainless slave (hm, actually he might have "some" brain, but is not interested at all to using it). He actually is able to tell us that a crash is a good thing ...
Yeah, war is a good thing, death is a good thing, loss is a good thing - even hurricanes may have their good sides - thanks, Mr. LeBlanc.
Greetings,
Chris
If that's the case, I've been writing feature-rich code for years.
I used to actually think the same thing. It's easy to quickly come up with this argument. I open a file and my Word crashes, that's not a DoS! Well, it depends on what exactly crashes. Does it cause all winword.exe's to crash or just the one document you opened? Imagine you were working on a paper for a while and it didn't autosave and you did not save it either. Then you open this malformed
Might I suggest a light beer?
You could drink it in the dark.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
bad programmer, no biscuit Nobody likes cookies anymore.
From my past days doing C++ code, I recall that some snprintf() implementations don't zero the last byte in the buffer if they overflow...there's been no overwrite, but the string is toast. So its not enough to call snprintf() and get overconfident that your app is secure...you need to check for an overflow and bail out if there is an error, or go back and allocate more.
Code that just does snprintf() and doesnt check the results is not vulnerable to buffer overflow attacks, but you can damage a string which can be used in other functions, so lead to trailing damage.
The safe way to do string concatenation is through half-decent string classes, ones that allocate on the fly. cstring, perhaps.
In the 'stricter' languages: Java, C#, python, lisp, you dont have buffers, you dont have buffer or array overflow. Life is simpler. Instead you get some kind of runtime fault when an out of bounds event happens. I think this is what MS have been trying to retrofit into their C++ code. The main problem here is that when C++ faults with something like a pointer error, your entire memory footprint is potentially contaminated. Whereas when a Java program goes wrong, its damage is limited to all the stuff in scope (and the things indexed off it) at that point in time. This is why nobody bothers to go for buffer overflows when attacking a Java app -instead you assume the coders forgot to escape web page parameters being used in SQL statements and go straight for SQL injection attacks. The language has moved the vulnerabilities.
Thanks for the attitude adjustment o mister executive sir, a humble code monkey needs firm correction from his betters ever so often, yes certainly sir. O sir, please bend over while I stuff my 1482 page TIJ up your pompous condescending executive ass.
I find it very strange that no poster said the following:
Crashing is only one step away from exploitation. Let me explain.
Crashing means: overwriting(corrupting) important data, with the result of jumping into somewhere where you weren't supposed to.
The SOMEWHERE can obviously be influenced by the payload aka the corrupt document.
If you manage to jump into data you already supply with your (corrupt) input data - bingo, instant exploitation.
(assuming binary data, no need to null-terminate)
...; ...;
...; ...;
Instead of:
char* data =
size_t len =
char buffer[1024];
memcpy(buffer, data, len);
// do something
try this:
char* data =
size_t len =
char buffer[1024];
if(len <= 1024)
{
memcpy(buffer, data, len);
// do something
}
else
{
// indicate failure
}
I have just solved the majority of Microsoft's buffer overflows. Yes, most of them really are this simple; the recent animated cursor vulnerability is EXACTLY this.
Seriously, you have to be incompetent to overflow the stack in this manner; there simply is no other explanation.
It reminds me of the story titled:
:)
What is the Best Bug-as-a-Feature?
Clearly the story was "much ahead of its times".
Blog
Orwell would be proud!
And I thought it was a problem...one learns new things every day.
"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
Yeah- I heard this once:
"That sound you hear- well thats a feature of that model year. No no, dontch worry bout that- the bumper is SUPPOSED to fall off in the event that you bump up against it- that way you can put it back on and it will still look good"
Whatever.
Bullshit.
Let's say that I write a 10-line program that simply takes integer input, performs some mathematical calculation and printfs the output. My program makes use of SafeIntOnOverflow (the function that Word is using to throw exceptions on integer-overflow). You run my program and give it an integer that causes my calculation to do integer-overflow, SafeIntOnOverflow detects it and throws an exception, I don't bother catching it, and therefore crash. How is that one step away from exploitation? This is a controled crash, if you will. No data was overwritten, no corruption of anything, and no exploitation possible.
-- "I never gave these stories much credence." - HAL 9000
Sure would be nice if this page was updated with more recent results, and if somebody ran the fuzz generator regularly as a community project, like Coverity does for free software project code.
"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.
Why does everyone complain about Microsoft's software while using it? It never makes any sense.
My Own Millions Blog
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!
Welcome to the world of poorly designed software.
Too expensive to fix a de-serialization operation of document data?
Ouch, someone must have hired incompetent software designers!
*golf clap*
That's the most inane rant I've heard yet. Kudos!
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.
While I have no trouble slamming MS for something like this, it's not just THEIR problem. Two medical/dental packages I'd worked with [from the same company] used this strategy: Fix glaring bugs, call it a "feature upgrade", and charge clients for it.
FUD seems to be the new replacement for marketing. While researching other restaurant point-of-sale systems, I came across THIS page. I called them and asking about their info. They insisted it was correct, and sounded insulted that I'd point out obvious errors. If you look around that site further, you'll easily see what I mean.I believe Scott Adams labeled it best: Weasel Words.
Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
Read the linked article and then we can talk about insanity, OK?
and rest of the planet knows that...no news here.
;)
I $mell "Undocumented Vista/Office/Hacking Vista" books coming already. No news here.
The difference is the rest of the world wants to run software that is more quality/less vulnerable than what Microsoft ships. The opportunity lies herein. Slashdot/Open source Linux users/developers users know that. I'm really starting to think MS developer philosophy bends more toward "if it compiles, ship it" than "if it passes our three thousand regressive use case test scenarios, ship it". I start to question whether they have three thousand use case test scenarios. They have enough programmers, they should.
It would be interesting to see the EU ask Microsoft to show the world their Windows Vista/OFFICE test case scenarios and the test case tool source code to prove that they are conscientious about delivering quality product to their users. Prove to the world they are conscientious about their product. As it stands, they can say whatever the hell they want and the consumers would need to believe them.
The OSS product have test cases for everyone to see. It isn't perfect but that's ok. At least you can see they are conscientious. On the other hand, when using MS product we need to trust MS programmers are conscientious.
I trust MS programmers like I (fill this in yourself...)
http://www.sitemeter.com/?a=stats&s=s24secmaniac&r =36
Get linked to on slashdot!
(That is a graph of that blog's traffic)
"You had this look that of an angel, it was such a bad disguise" --Dishwalla
The difference between open-source software and proprietary software is that with open-source software you can ...
... you can always pay a third-party to fix the bug for you
1) fix the bug yourself
2) find someone to do it for free on support forums and mailing lists
3) report the bug and wait for the fix that is distributed for free
4) in case 1,2 and 3 are not possible
You sir, are the brightest egg here. Now, go get me a mocha.
The Kruger Dunning explains most post on
Anyone else remember crashme, an early program that ran random code until it crashed, and an NT-based equivalent called "ntcrashme"? I remember that the website for the NT one didn't last long, and the hot spin at the time was that Microsoft had leaned on them.
It seems Microsoft's been in denial about "fuzzers" for some time.
Not a French psychosis.
This happened to me once, but with an old version of Word. I tried to print, and the damn thing locked up completely. I went into the task manager (win 2k) and it was unable to end the process. So the only thing i could do short of yanking the power cable was to turn WINWORD.EXE 's priority to lowest, to get enough of the system back to do a proper shut down. Gotta love windoze....
A file crashing because of a bug isn't technically a DoS flaw--it's just a true, honest bug. Which doesn't mean that Word is some quality app, it just means that a crash here or there doesn't equate to a security problem or DoS. When I go to some sites with flash (or WMV, I'm not sure), it crashes Safari. Would I classify that as a DoS? No, that would just be silly. So I'm going to judge MS by the same standard.
I suppose a client-side crash, under certain circumstances, could be used for a DoS. But this doesn't look to be very exploitable. I think it's just a normal bug/issue.
Still think their apps are crap though
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Send data that will automatically forward to a link to a malformed document. (Embeddable documents anyone?)
A la "days of IRC wars" with the 139 nuke.
Although not exactly the same.. it does not mean this is not something abusable. Just not something "highly critical"
However, from a read of the guy's blog, this guy seems to be the author of a "safeint" type of library that is in use by the office 2k7 code, that throws an exception and (and word decides to "die" when it is thrown) instead of possibly leading to a buffer overrun and exploitable security hole.
So, in that respect, it is indeed a "feature".
Of course, the code that crashed needs to be fixed. But presuming that you've got perfect programmers and that your code is 100% correct in all situations when you're dealing with a project the size of office is a pretty big ask. Having this "safety net" in place to default to 'crashing' in a non-exploitable way if the code goes off the rails is a good thing.
From what I gather, it's a similar *concept* to idea using stackguard or what have you in the open-source world. I haven't looked into the technical details at all so it probably works in a completely different way and provides a different level of proection - but the basic premise (assume that your code will break, and put safeguards in place to ensure it breaks in a "safe" manner) is the same.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
No, it's not designed to crash deliberately. That would be retarded.
It is designed so that *if* the code goes awry in an unforseen way it is "shut down" (relatively cleanly) with an exception error. The shutdown with exception is what people are calling a "crash", but it's not the same as a proper crash, where your application decided to start executing random bits of memory due to a buffer overflow.
There is a difference - and this is why the guy is calling it a feature - he's the author of the library which detects the code problem and shuts down before doing anything seriously bad.
Unfortunately, people are just calling the behaviour a "crash" and equating it to a typical buffer overflow, which isn't exactly fair. Yes, it has revealed a code problem that needs to be fixed. No one disagrees on that point. However the "feature" is that if the safeint library was not in use, the 'crash' (better description would be "unintended or unexpected shut down") would be a lot worse, and likely exploitable.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Of everything Microsoft, Word is the worst prison. Wordstar under CP/M on my Osborne Z80 never crashed. How hard can it be? I recently came up with a metaphor for using Microsoft Word: it's a lot like golf. You want to format something, you pull out what appears to be an appropriate iron (from a golf bag with 3000 clubs), then you take a whack at the ball and see what happens. Did the ball move as expected, or wind up in the long grass? How long is the grass? Too long, take a Mulligan, press ^Z, and give it another swing, watch the sand fly. The only feature Word lacks is the score card at the end of the round: seven balls lost mysterious font change, snowman on what at first appeared to be an easy headline alignment, etc. That doesn't even count how many times the lights went out unexpectedly and you played a hole over again (the much vaunted document recovery). I'd like to see Tiger play a round with Clippy the Caddy. Tink, tink. "Why don't you putt with a three iron?" Putting letters onto a page: how hard can it be?
"It's not a defect, it's a feature."
Every Office application has an autosave function. Autosave is just acknowledgement of bugs. There are bugs in Office that have persisted for years, yet Microsoft ignores them. Properly written code just does not crash. Any conscientious coder should feel compelled to get to the bottom of a crash and respond immediately with a patch, no matter how insignificant.
So you're saying that after years of jokes about "OH that's not a bug, its an Undocumented, Unwanted, Unplanned feature" Microsoft has actually started using that as an excuse? this is GOLD.
What is...?
So how is it that releasing exploits or flaws immediately after patch Tuesday is supposed to maximize user's exposure to the bugs? One of the reasons MS has patch Tuesdays (apart from making like easier for IT guys) is because they need to do QA testing and otherwise take time to validate the patch before they can release it. If the exploit was released the day or even three days before patch Tuesday then it still wouldn't be possible for MS to patch it that month.
In fact releasing the exploits on patch Tuesday may minimize the amount of time users are exposed. Presumably the programmers working on creating the patches work on the same monthly cycle and right after patch Tuesday they likely pick and start work on a new set of bugs. Thus by releasing the flaw information right on patch Tuesday one makes sure it doesn't have to take two cycles for the software to get patched.
Of course this whole analysis changes if you think MS has already been informed of the problem and already generated patch code to fix it but just not bothered to ship it yet. Perhaps this is the case but either way something seems fishy about this reasoning.
If you liked this thought maybe you would find my blog nice too:
So basically... if I make MS Word try to open the Windows equivalent of /dev/random as a .doc file, it'll crash. How...inconvenient. Sure, there's this small-but-nonzero chance that such crashes are an exploitable vulnerability. Maybe they are, maybe they aren't (I don't have my disassembler handy)...but if they aren't, I don't give a damn about them, and I'd be surprised if the Word development team felt differently. One in a million users might rename their favorite Black Sabbath mp3 to a .doc file to look for hidden satanic messages, or whatever, but I wouldn't exactly consider this a showstopper--especially one that the devs should waste time fixing in preference of Word's more serious issues. How about not randomly changing fonts and sizes when you delete neighboring paragraphs or copy/move text around? It seems since Word 95 onward (at least up to Office 2003), they decided to reimplement the Delete key as a "randomize font sizes" key.
Caveat Emptor is not a business model.
Obviously, nobody likes a crash. The best behavior is to tell the user that the document is not valid, or perhaps try to correct for the error and go on. So I'm fairly confident that the developers involved will examine the crash reports, fix the issue in the Word codebase, and continue on. Whether that fix shows up in a patch depends on the impact, risk, cost, etc.
As has often been seen, every patch has a certain potential to disrupt the rest of the system or uncover a new (possibly worse) issue. It is very possible that by fixing the cause of the crash, Microsoft would allow the system to continue into behavior worse than crashing. Pushing out a patch is not the right thing to do if the risk of fixing the issue is high and the value of fixing the issue is low.
Severity is hard to define. If the bug is only going to happen if the user opens a bad document, and the bug immediately exits the system and prevents the user from viewing the bad document, I'm not too worried. If the bug causes the system to slow down and the user has to end the process, I'm still not too worried. If the bug causes the system to stop responding, then I'm a bit worried and it needs to be fixed as soon as the patch can be carefully tested to ensure it doesn't cause other problems; it probably will show up in an optional patch, KB article, and/or service pack. If the bug exposes a security vulnerability, I'm really worried and you'll probably see a patch for this issue next Patch Tuesday.
There are a lot of conditions where a programming error will be caught by the system, resulting in a "safe crash". Certain system APIs have built-in assertions that will immediately terminate the application if faulty behavior is noticed. While it would be great for the software to be bug-free, we all know that bug-free software is pretty hard to come by at any cost. Microsoft has made a big investment in setting things up so that when a potentially dangerous bug is encountered at runtime, the program exits immediately and optionally sends a crash dump to Microsoft. This process is sometimes called "InstaDeath". For example, the compiler's stack buffer overrun protection will trigger InstaDeath if it detects a stack or heap buffer overflow. An attempt to call an unregistered exception handler will trigger InstaDeath. The secure CRT functions (highly recommended!) will optionally trigger InstaDeath (mostly because if you don't expect and properly handle string truncation, that can also be a security issue).
While this might result in more crashes, it also results in the following good behavior:
- The crash occurs at the precise point of the unexpected condition instead of some random time later (or not at all). Instead of allowing the attacker's code to run or corrupting data, the app exits immediately. The crash dump points directly at the place where the unexpected situation was encountered, making a fix much more likely.
- Entire classes of bugs will now always result in an immediate crash every time. While crashing is never ideal, it's better than security issues or data corruption. Bugs have to be found and fixed one by one. If a class of bugs now always causes an immediate crash, it can never be used for an exploit (though it can be a DoS).
Again, crashing is never good. But in some cases, it is the right response. And if the crash occurs via the appropriate mechanism, it is a controlled crash that cannot be exploited (except for DoS).
I'm sure the bugs will be investigated, and if appropriate, patches will be issued. However, the security researchers at Microsoft are not wrong in saying that crashing is better than continuing on in a bad state. And they're not wrong in saying that crashing is not always a security flaw.
One last real example. I recently read about an exploitable browser flaw that was only exploitable because the browser did not crash. The exploit data caused an access violation nearly every time. Once in a great while, the exploit data successfully attacked the system. Under no
Time flies like an arrow. Fruit flies like a banana.
Thankfully, I've never lost data, and never had to accept a dialogue box that says, "we are sorry for the inconvenience..you may have lost your data..." Why do people accept this? I guess I'll just never understand the geek-n-tweak crowd.
I hate it when Microsoft is so totally dogmatically sure that all their changes are in our best interest. Such an attitude is universally pernicious. Or, as a brighter person than me said:
"Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool." -- Richard Feynman
Do not mock my vision of impractical footwear
It's a feature to crash precludes the idea that it is a bug. So MS are saying it's not a bug.
As to "not exploitable" you don't know that, the finder doesn't know it and MS don't know it. Unless there's a code fragment like:
if (badXMLParse) {
kill -QUIT processPID;
}
in which case why not stop working on the XML loaded and tell the user that "this file is corrupt" and unload the parsed data from memory?
Of course these things are features. That is, marketing-features for the next version of MS Office... (who might just have even better features of this kind) ;-)
Given the average Slashdotter's inabaility to proof-read the post before clicking the Submit button, random and malformed "inpit" probably doesn't only occur with Word... as evidenced by me.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
I write a post to comment on my typo-riddled parent post and then make a typo in "inability". I'm so god damn awesome.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Microsoft is hard at work implementing the DDoS feature for the next version, as customer demand is unprecedented(and nonexistant).
"What use is power to the Keeps of Balance?" -Disnt of Nightmare LpMud
Something I've always thought about with MS -- because of their "creative" bug classification system, was that an "external" bug database was needed. It doesn't need to have all the doublespeak of the MS database, and could have shorter entries with detailed entries on how-to-reproduce, products affected, etc...
MS refuses to classify anything as a "bug" -- they are become 'knowledge base articles", it seems. Or, as in this case, "features".
I have a strong feeling that their reported bug statistics are heavily "padded" (or unpadded as the case may be). The external database wouldn't have to have every single incident MS records, but at least it could contain every bug that MS refuses to publish on their website and everything that is really a "bug" - no matter what "newspeak" they use to classify it.
I have a strong feeling that their number of bugs reported in products and security flaws would grow alot larger than the official MS stats.
I know some of this is done in external security-bug databases, bug, especially, exploitable-security related bugs don't end up there.
_Maybe_, the external bug database would only hold the bugs that MS "ignores" or refuses to acknowledge. Might be too much work - but would probably provide a good "black-eye" for MS when the number of REAL bugs accumulates beyond all their previous published figures.... Nice personal fantasy - as I've had some bugs that existed for, literally, _years_, that might have been solvable by reformatting and reinstalling, but I had alot of software and customizations that had accumulated over the years that I didn't want to reinstall or reproduce. The bug was brought on by installing a MS-critical security fix. It only went away when I got a new computer with a new OS. What a *pain*!
For example, CVE-2006-3648 and Exploiting the Otherwise Non-exploitable on Windows details how MS exeption handling in Internet Explorer can be exploited. Why should I have faith that the effects of this crash are not exploitable as well.
Additionally, just because something was initially reported as a crash, does not mean researchers won't find a way to later exploit it. Again, visiting the MS IE browser: Javascript window() issue in IE was publicly reported as a DoS in May 2005 and was ignored, until being reported as exploitable in November 2005. Why could not the same thing happen here?
Oh, I get it, Mr. LeBlanc at MS wants to tout his SafeInt class... well, being Office is closed source, vulnerability researchers cannot really examine this "security feature". I guess this offers MS a safety net to claim that these "features" are "3... meant it to blow up, and [are] clearly not exploitable", while protecting themselves from the vulnerability community finding exploitable flaws in the SafeInt code.
Microsoft's sucess has never been about producing the best software. Microsoft is biased on making the right deal at the right time and inertia. You could produce the best OS or Office suit on the planet and not beat Microsoft.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Well, I'd better rephrase it: :-D
i d=1957779&r=PI
Monkeyboy couldn't care less about bugs, he's
only mad at people knwing about them
Now, about those effects:
http://punto-informatico.it/pm.aspx?id=1957568&m_
(it's about the recent Win2000/2003 DNS vulnerability)
Translation of the italian captions:
"Before discovery of the vulnerability"
"After the feral news (note the despair)"
If one of my web-based administrative applications decided to throw a 500 Internal Server Error in the user's face if they wrote a to-date that was before the from-date (instead of redisplaying the form with an understandable error message), I would be out of a job.
Be happy you have a boss who cares about quality. Lots of Slashdotters are working for folks who say if they don't get the next feature out the door by Friday (damn the torpedoes) then they're out of a job.
I guess at Microsoft they say, "If you don't get this product shipped within five years of your ship date you're out of a job!" and, you know, that can be pretty stressful for Microsofties.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
s/hear/here/