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.'"

15 of 411 comments (clear)

  1. Let me see... by AKAImBatman · · Score: 4, Insightful

    ...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.

    1. Re:Let me see... by belmolis · · Score: 4, 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.

    2. Re:Let me see... by Deadbolt · · Score: 5, Insightful

      I hope you're not serious; if you are, I'm never letting you near any code I'm responsible for.

      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.

      --
      "Honey, it's not working out; I think we should make our relationship open-source."
    3. Re:Let me see... by tkinnun0 · · Score: 3, Insightful

      Exceptions can be thrown, but they should be caught and used to halt the "bad actions", and revert back to a normal program state. In an unsafe language, like C++, as is the case with Word, once you have encountered undefined behavior, all bets are off. There is no way to be sure from within your program that you are not already running the attacker's code. The only thing you can do is tell the OS to shut down your program and hope the call goes through.

      In a safe language, like Java, and with a program that can be expressed as a work queue, you can isolate changes to global state and, in the case of a work item failing, provided your thread isn't in an endless loop, ignore the results from the item and carry on. Of course this doesn't mean that the global state is valid. In fact, a failing work item may be an indication that the program is being moved towards an invalid state, and the proper thing would be to crash.
    4. Re:Let me see... by Jherek+Carnelian · · Score: 3, Insightful

      A program must be able to recognize invalid input and take appropriate action. Allowing (or forcing) a crash is NOT acceptable.
      Sounds like you've never heard of a kernel panic.

      Sometimes immediately dying is the best option - when you reach a point in the code that "should never happen" then you can not count on the integrity of anything else within the program at the time. At that point the ONLY safe option is to "go boom" thus assuring that whatever the problem is, at least it won't corrupt anything else.
  2. Better recovery... by kebes · · Score: 3, Insightful

    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.
    Okay, handling crashing properly (saving some data, logging errors, etc.) is of course nice. However even the most graceful crash is, as far as "recovery mechanisms" go, pretty bad. A proper recovery mechanism would be rather less disruptive to the user... for instance a prompt that warns the user that something bad happened and the document is being rolled back to before the last action occured. Similarly logging of errors can be done properly without crashing the entire application. A log-file is generated, and the user keeps working even though the last action didn't work, hopefully with some feedback indicating why the last action didn't work.

    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.
  3. But seriously.... by beef623 · · 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.

  4. Re:Let's just get this out of the way then... by Mateo_LeFou · · Score: 3, Insightful

    "Um, read that again, and see if you can find the problem. ;-)"

    I found two:
    1. No one reads TFA
    2. There are plurality of TFAs ...which means there's an error in your statement, which should read
    "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
  5. Re:I didn't know that by Skadet · · Score: 5, Insightful

    Why spend on testing, when you got paying consumers to do the bug reports for you?
    Because anything more complex than calc.exe is going to have weird bugs that can't discovered within a realistic timeframe to keep release dates. And if I'm not mistaken, open-source software does the same thing. BugZilla anyone? If it weren't for user feedback, a great majority of bugs wouldn't get fixed.
  6. explosive code? by Ajehals · · Score: 4, 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.

  7. Firefox crashes on malformed intput too by 140Mandak262Jamuna · · Score: 3, Insightful

    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
  8. Re:Input validation by idontgno · · Score: 4, 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.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
  9. I guess it is an attitude problem. by alberion · · Score: 3, Insightful

    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. :)

  10. Walk into a store by Peaker · · Score: 3, Insightful

    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!

  11. Re:I didn't know that by xero314 · · Score: 3, Insightful

    You can write bug free software, it's just several orders of magnitude more expensive and time consuming to write it. I was gonna let all this slide by but after reading that line I had to jump in. This is complete rubish. An absolute line made up by supporters of Agile development and Frauds out to suck millions of dollars from ignorant venture capitalists. Look I'm sick of hearing this. As a software Engineer I have experienced bad software development and good software development, and believe it or not, good, solid, bug free (99.9%) software takes less time to design, write and test, than the majority of the crap beta software corporations like MS spits out to the unsuspecting public. And that's not even getting into the fact that programs like word are far more complex than they need to be to accomplish exactly what they end up doing.

    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.