Forgot your password?
typodupeerror
Security Programming Software Microsoft Technology IT

Word 2007 Flaws Are Features, Not Bugs 411

Posted by Zonk
from the i-thought-that-was-just-a-programmer-joke dept.
PetManimal writes "Mati Aharoni's discovery of three flaws in Word using a fuzzer (screenshots) has been discounted by Microsoft, which claims that the crashes and malformed Word documents are a feature of Word, not a bug. Microsoft's Security Response Center is also refusing to classify the flaws as security problems. According to Microsoft developer David LeBlanc, crashes aren't necessarily DoS situations: 'You may rightfully say that crashing is always bad, and having a server-class app background, I agree. Crashing means you made a mistake, bad programmer, no biscuit. However, crashing may be the lesser of the evils in many places. In the event that our apps crash, we have recovery mechanisms, ways to report the crash so we know what function had the problem, and so on. I really take issue with those who would characterize a client-side crash as a denial of service.' Computerworld's Frank Hayes responds to LeBlanc and questions Microsoft's logic.'"
This discussion has been archived. No new comments can be posted.

Word 2007 Flaws Are Features, Not Bugs

Comments Filter:
  • by Anonymous Coward on Friday April 13, 2007 @02:46PM (#18722311)

    Word 2007 Flaws Are Features, Not Bugs
    That's right and the price you pay for it is an investment, not a complete waste of resources.

    What's the matter? Did the Slashdot editors lose their English-to-Microsoft dictionary again?
    • Re: (Score:3, Funny)

      by eneville (745111)

      Word 2007 Flaws Are Features, Not Bugs

      That's right and the price you pay for it is an investment, not a complete waste of resources.

      What's the matter? Did the Slashdot editors lose their English-to-Microsoft dictionary again?

      The denial of the denial of service is what really grinds my gears. There are so many companies who listen to their customers about things like this. With a high profile product the company should really bring it to the attention of their developers.

    • Re: (Score:3, Funny)

      My favorite is turning on Track Changes, then selecting text and using Shift+F3 to cycle the text case.
      The fact that you changed, for example, 'rtfa!' to 'RTFA!' is _not_ included in Track Changes. Oops.
      Reported that a version or two ago, and the report came back (promptly, I might add, as I paraphrase) "That behavior goes all the way back to Word97. We're going to label that 'Behavior by Design'".
      If Word were a housecat, it would be conceptually similar to the Robin Williams routine, where Robin prete
  • I didn't know that (Score:2, Interesting)

    by alberion (1086629)
    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.
    • by Skadet (528657) on Friday April 13, 2007 @02:58PM (#18722583) Homepage

      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.
      • 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. :)
        • Small hint: they do exactly that.

          To quote Para. 16 of the Windows XP Home EULA:

          Except for the Limited Warranty and to the maximum extent permitted by applicable law, Microsoft and its suppliers provide the Software and support services (if any) AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the Software, and the provision of or failure to provide support or other services, information, software, and related content through the Software or otherwise arising out of the use of the Software. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THE SOFTWARE.

          Seems pretty much the case to me.

          Don't even try the "Click throughs not legally binding!". It doesn't need to be binding for this - but to claim they don't sell software AS IS is an absolute fallacy, trivially demonstrable.

      • Re: (Score:2, Interesting)

        by ady1 (873490)
        I agree with the complex software part. The tiny bit of problem is the Microsoft is charging quite a bit of money for the honor of being a beta tester.

        On a completely different note, I've vista installed on one of my PC and the explorer crashes quite often for a 499$ OS.

        My colleagues and friend ask me all the time if they should get vista and I tell them to not waste their time. Even one of my friend bought a laptop with vista preinstalled and he had to revert to XP right after because explorer crashed so o
  • I Wish (Score:5, Funny)

    by Mockylock (1087585) on Friday April 13, 2007 @02:50PM (#18722405) Homepage
    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.
  • Let me see... (Score:4, Insightful)

    by AKAImBatman (238306) * <akaimbatman@@@gmail...com> on Friday April 13, 2007 @02:50PM (#18722411) Homepage Journal
    ...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.
    • Re:Let me see... (Score:5, Insightful)

      by belmolis (702863) <billposerNO@SPAMalum.mit.edu> on Friday April 13, 2007 @02:56PM (#18722535) Homepage

      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.

    • Re:Let me see... (Score:5, Insightful)

      by Deadbolt (102078) on Friday April 13, 2007 @02:57PM (#18722557)
      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.
      • by zappepcs (820751)
        I agree with you but would like to point out that there are times and circumstances where a crash/reset is a better option. In RT comms systems, down time is far more expensive than a crash/reset could be. If a critical system or process is thrown into an unrecoverable circumstance such as corrupt table index etc. it is much preferable to crash/reset and start anew than to wait and stop processing traffic for 2 hours until the technician arrives to push the reset button. The recovery process associated with
        • by d-rock (113041)
          I run a pretty big network and if my primary router resets because the watchdog timer trips (basically what you're describing here), we send the crashdump log to the vendor and they fix the bug. I've never had a vendor say "oh, a crash is normal and appropriate behavior."

          Derek
        • 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 a
        • Re:Let me see... (Score:5, Interesting)

          by misleb (129952) on Friday April 13, 2007 @04:20PM (#18723879)
          The point is that a malformed documented shouldn't throw a word processor into an unrecoverable state. That is a bug. I don't know whether or not it is a denial of service attack. That is debatable, but not properly handling an exception in a document is definitely a bug. A word processor can simply tell the user, "hey, this document is fucked, I can't open it." If it just crashes, the user could possibly lose data in other open documents. And that is a Bad Thing(tm).

          -matthew
      • Re:Let me see... (Score:4, Insightful)

        by Jherek Carnelian (831679) on Friday April 13, 2007 @04:38PM (#18724203)

        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.
        • Re: (Score:3, Insightful)

          by Eivind (15695)
          A kernel panic indicates one of two things:

          Either a bug in the kernel (included loaded modules)

          Or a malfunction or bug in one of the components the kernel needs to run (example: flaky memory)

          The first are the most common; we somehow got into a state we shouldn't be in. Thus we must have messed up, and the safer choice is to refrain from further actions, since we may be insane in general. These are nevertheless bugs, and should offcourse be acknowledged as such and fixed when possible.

          The second isn'

        • Re: (Score:3, Insightful)

          Sometimes immediately dying is the best option - when you reach a point in the code that "should never happen"
          Yes, but no kind of input thrown at your program should result in the "it should never happen" code being reached (it's called that for a reason). If it is, then the program has a bug.
    • Re:Let me see... (Score:5, Interesting)

      by Ckwop (707653) * <Simon.Johnson@gmail.com> on Friday April 13, 2007 @03:01PM (#18722633) Homepage

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

      The Open BSD guys have a philosophy: "The only difference between a bug and a vulnerability is the intelligence of the attacker."

      I wish more programmers held this view! A bug is an undefined state of the program. It's quite clear that this is a dangerous position for your program to be in. Bug really are baby vulnerabilities. It's best to remove them as soon as you find them.

      Simon

    • Re:Let me see... (Score:5, Interesting)

      by kebes (861706) on Friday April 13, 2007 @03:03PM (#18722689) Journal
      I totally agree that calling this a security flaw or DoS is silly. Until it is actually used to exploit the program, it's not a confirmed security flaw.

      However using bad documents to crash Word is still a flaw in Word, in my opinion. The application should just say "Can't open bad/corrupted document" and let the user keep working. In the blog he says:

      The theory is that it is better to crash (at least with client apps) than it is to be running the bad guy's shell code.
      I understand the rationale, but I would argue it's rather sloppy programming that uses a crash as a means to prevent such bad things from happening. Exceptions can be thrown, but they should be caught and used to halt the "bad actions", and revert back to a normal program state.

      Obviously it is better to crash than to execute arbitrary enemy code. However it's better still to just refuse to execute arbitrary code, but otherwise keep running. The problem with using crashing as a security system is that then the "bad guys" will try to crash your application on purpose (calling it a DoS is a stretch, mind you), which opens up new security problems. (A crashing app may expose other security vulnerabilities, disclose otherwise protected information, destabilize other apps/the OS, etc.)
      • Re: (Score:3, Informative)

        by ppanon (16583)
        It depends. Does the crash only close down that document? Or does it also crash and lose the changes to the other documents that you've been making for the last two hours? I'm betting on the latter since all open Word documents seem to be managed under a single process. And to me losing pending changes to other documents is a DoS.

        How would you feel if you opened a word document, which you received in an e-mail from a co-worker, that then crashed Word and made you lose some important work you had just been e
      • Re: (Score:3, Insightful)

        by tkinnun0 (756022)

        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 you

    • by PCM2 (4486) on Friday April 13, 2007 @03:26PM (#18723029) Homepage

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

      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.

    • First, the Microsoft guy says that the reported behavior would constitute a DoS:

      If you can crash my app so that I can't restart it, or have to reboot my system, well, OK - that's a DoS.

      The other article, based on the security researcher's work, calls the same thing a "denial-of-service-like situation":

      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 disagreement is not over how to describe

    • It's a bad document. Word crashes. Life goes on.

      You're right, you know. And you're not just right about word - this design paradigm clearly extends across the entire Microsoft product line, from the most basic to the most mission-critical:

      "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

  • It's officially 1984 (Score:3, Interesting)

    by Mateo_LeFou (859634) on Friday April 13, 2007 @02:51PM (#18722427) Homepage
    The spokesthing actually contends that the crashes are "a by-design behavior that improves security and stability"
  • Input validation (Score:2, Insightful)

    by Skadet (528657)
    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.
    • by idontgno (624372) on Friday April 13, 2007 @03:19PM (#18722931) Journal

      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.

  • It seems to be a typical response from Microsoft.

    Another example I came across recently is here [microsoft.com]. What's the point of designing as such?
    • Re: (Score:2, Insightful)

      by castle (6163) *
      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.
  • Better recovery... (Score:4, Insightful)

    by kebes (861706) on Friday April 13, 2007 @02:52PM (#18722457) Journal

    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.
  • by Red Flayer (890720) on Friday April 13, 2007 @02:53PM (#18722473) Journal
    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?
    • by mikelieman (35628)
      If you can detect someone trying to exploit it, why not just handle the exception properly, not import the document, and not crash?

      • If you can detect someone trying to exploit it, why not just handle the exception properly, not import the document, and not crash?As hinted at by the MSFT spokesperson, for data collection about the exploit? Who is going to allow the app to phone home with info unless it seems like something serious is going wrong? Most users will happily allow Word to phone home with details when it crashes... plus if they let the exploit begin, they get a clearer picture of what the exploit looks like in situ.
        • by init100 (915886)

          As hinted at by the MSFT spokesperson, for data collection about the exploit?

          If I used Word and lost a document just so that Microsoft could do some data collection, I'd think that they'd have their priorities seriously wrong.

          • f I used Word and lost a document just so that Microsoft could do some data collection, I'd think that they'd have their priorities seriously wrong.
            1. Documents are recoverable (as specified in TFA). If you've had Word crash on you while working on unsaved documents, you would know this.

            2. Who ever said that Microsoft had their priorities right?
  • But seriously.... (Score:4, Insightful)

    by beef623 (998368) * on Friday April 13, 2007 @02:53PM (#18722481)

    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.

    • by ivan256 (17499)
      I'd like to see the actual code that is forcing the crash. I'd say there's a 50/50 chance that they're hitting an assert. The other 50% is that they're completely full of crap, and they got lucky that this causes a crash instead of an exploit.
    • Sadly his attitude is common to many IT departments.
  • Word is a bug (Score:2, Insightful)

    by dbfruth (707400)
    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.
  • How Long Before... (Score:3, Informative)

    by Evil W1zard (832703) on Friday April 13, 2007 @03:01PM (#18722637) Journal
    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...
  • explosive code? (Score:5, Insightful)

    by Ajehals (947354) <a.halsall@pirateparty.org.uk> on Friday April 13, 2007 @03:05PM (#18722711) Homepage Journal

    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.

    • by PCM2 (4486)

      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

      But isn't this the whole point of the exception-handling model of software error recovery? Back in the old days, any bug could potentially take down the whole system, only it didn't matter because the OS wasn't multitasking anyway. Under the exception-handling model, an unforeseen conditi

      • Re: (Score:3, Interesting)

        by drinkypoo (153816)

        But isn't this the whole point of the exception-handling model of software error recovery?

        There's a reason we call it a crash (or an abend.) It's because we weren't expecting it. We're not talking about a demolition derby here.

        If an exception causes the program to quit safely, it's not a crash, it's an expected termination.

  • by 140Mandak262Jamuna (970587) on Friday April 13, 2007 @03:06PM (#18722727) Journal
    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.
  • 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
  • by Chris Mattern (191822) on Friday April 13, 2007 @03:12PM (#18722813)
    Microsoft declared that they are not crashes at all; they are "rest breaks".

    Chris mattern
  • 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
  • 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
  • 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:

    if (isExploit){
    crashApplication();} // 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
  • 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
  • by brennanw (5761) * on Friday April 13, 2007 @03:47PM (#18723379) Homepage Journal
    ... before Microsoft started getting all their ideas from me, instead of the other way 'round:

    http://www.ubersoft.net/d/20030224.html [ubersoft.net]

    but more specifically

    http://www.ubersoft.net/d/20030228.html [ubersoft.net]

  • 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?
  • by guruevi (827432) <evi.smokingcube@be> on Friday April 13, 2007 @03:48PM (#18723393) Homepage
    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.

You are in a maze of little twisting passages, all alike.

Working...