Slashdot Mirror


HTML Rendering Crashes IE

SlimySlimy writes "According to this article on Secunia, a new IE exploit was found that crashes almost any version of Internet Explorer past 4.0 with just 5 lines of plain HTML code (no JavaScript, ActiveX, etc.). If you're very brave, you can test/crash your IE by going here." There's also a note on SecurityFocus.

15 of 887 comments (clear)

  1. So.... by The+Bungi · · Score: 4, Insightful
    It's not a vulnerability. It's a bug. It's a stupid bug, but a bug nonetheless. I used to consistently crash Mozilla on some Hotmail pages. But I didn't submit it to /. as a great story to hysterical giggles from the peanut gallery.

    Slow news night, eh?

    1. Re:So.... by zook · · Score: 5, Insightful
      First: I agree.

      Second: It's simple. It's cute. It's the kind of bug that makes a dev go, "Doh!", and so it's not absurd to show some interest in it. It's also a fun game to try to pin down what the problem is.

      Third: Does it warrant a /. story? Have you seen half the stories that come through here? ;)

  2. Re:bah by gerardrj · · Score: 5, Insightful

    People are up in arms over this because Bill Gates made it priority one in the company to make their software more secure and more reliable. This is just another blatent example of how they are failing in that mission. (This and the almost daily security updates).
    Here we have a simple bug that should be a test case. The word "crash" is not required, just that the type directive has a null value since it is not followed by an equal sign.
    The code would not hang the browser. The code would crash it just the same as it is again missing the equal sign. It's completely concievable that a developer that hand codes HTML would accidentally omit the character.

    This is simple buffer underflow checking: "does the thing I just recieved have the minimum expected size/value?" and just like all the buffer overflow issues, they don't bother checking the untrusted input before sending it off for critical processing.

    --
    Article X: The powers not delegated... by the Constitution...are reserved...to the people
  3. Worth Pointing Out, I Think by coloth · · Score: 5, Insightful

    I've crashed IE 6 several times with this HTML just fooling around, and each time, an exception is raised, a debug report generated, an optional offer is made to submit the report to the OS manufacturer to inform them of the problem, upon which immediate technical support is often given. After that action is complete, the OS remains stable, and the crash can be repeated ad nauseum, experimenting with different tags/debugger experiments/versions.

    That is in a consumer OS (XP Home) that costs less than $100, and has tens of thousands of commercial apps available in almost every language. (probably millions if you include shareware/freeware)

    Whether it's my mom or another engineer, I feel pretty good about telling them XP is a solid OS that can do what they need. (likewise with IE)

    Not many years ago, it would have seemed pretty petty to obsess about such a bug--and that's when it would've forced a reboot.

    I'm not shy about criticizing MS when appropriate, but to come from Windows for Workgroups to XP in 10 years is pretty impressive, especially for a company of its size.

    If it were me, I'd spend my time debating the Software Formerly Known As Palladium, and not lose the forest for the trees by mocking MS for this kind of item. I fart bugs bigger than this.

    --

    Machines take me by surprise with great frequency. -A. Turing

  4. Use a fresher Phoenix by peterwilm · · Score: 3, Insightful

    Unfortunately, 0.5 is very old and there are only nightly releases since then. Try the nightly build from March 20th. It haven't managed to crash it once in those weeks.

  5. Re:OS X IE Is Unaffected by Elwood+P+Dowd · · Score: 4, Insightful

    Somehow I imagine that the folks at securityfocus.com would check pretty carefully for that. If there were serious danger involved, they'd either give MS some time to fix it before this release, or they would have told us the whole story.

    So hold your chickens before they jump the conclusion.

    --

    There are no trails. There are no trees out here.
  6. Re:Inquirer says one line by Selanit · · Score: 4, Insightful

    I just crashed my copy of IE (5.00.2614.3500) with no more than .

    And anyway, even if your version requires more than that, it can still be all on one line, eg:

    <html><form><input type crash></form></html>

    Since carriage return/line feed pairs are totally unimportant in HTML (except with the <pre> tag, and maybe one or two others), it's silly to talk about how many "lines" it takes anyway.

  7. Bugs, crashes by fm6 · · Score: 5, Insightful

    HTML clients are supposed to do skip over input they can't render. And in general, software should do something reasonable when it can't deal with input. Like deliver an error message. Crashing is always evidence of a bug, whether the data that caused it is buggy or not.

  8. Re:mozilla crashes too by JimDabell · · Score: 4, Insightful

    Everybody who has spent any time developing web pages has learnt that bad (and sometimes even good) html can crash browsers.

    I can't think of a browser released in the past couple of years that *crashes* on bad HTML, except for this particular issue. Misrenders, yes, but crashes, no. Bad javascript is another issue; you can protect yourself from that quite easily, and most of the time the browser catches infinite loops, fork bomb-style attacks, etc anyway.

    <tidbit type=outdated>
    Netscape 3 had a neat crash code:
    <script>delete new Location</script> The neat part about it is that 2 of those 3 words were undocumented.
    Of course any attempt to pass that as a security concern back then would have been laughed at. loudly.
    I'm not sure what has fundamentally changed since then.
    </tidbit>

    IE has become a standard part of the Windows OS. As more and more applications use it, the impact of crashing greatly increases.

  9. Re:Two points of significance for crashes. by Spoing · · Score: 4, Insightful
      1. No matter what the input stream, the application should not respond by crashing.

      Man, do I wish someone would tell the Mozilla team that...

    Got a current example?

    --
    A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
  10. Re:So is IE 5.1.6 on OS 9.XX by b1t+r0t · · Score: 4, Insightful
    Even if exactly the same code was used, it still wouldn't crash on the Mac. Why? RTFL, people. It's a null-dereference bug. That means something tried to access memory location zero. Apparently under Winderz, location zero is not mapped to anything and causes a crash from an invalid memory access.

    Under Mac OS 9 and earlier, memory location zero was explicitly a real memory location. I wouldn't be surprised if null accesses under OS X also don't cause a crash. So this bug wouldn't cause a crash on a Mac, period.

    It's really amazing how many people posting here have stupid conspiracy theories about this, like how it's an intentional mis-feature to test crashing the browser, and how they think the word after 'type' means anything. Look folks, the problem is that 'type' is naked, when it should be 'type="TEXT"' or something similar.

    --

    --
    "Open source is good." - Steve Jobs
    "Open source is evil." - Microsoft
  11. Re:Crashing != bug by satch89450 · · Score: 4, Insightful
    I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.

    I'm sorry you don't mention the name of your company, because your company makes software that should be shunned. No software should respond in an astonishing way when fed valid data that is outside of the domain of the function -- it should do range-checking and set an appropriate error flag and return to the caller with something, even if that "something" is a NAN. Even when fed absolute junk, it should detect the junk and error out in a predictable manner.

    In particular, taking down the application (and perhaps the entire system it's running on) is not an option.

  12. Re:Whoa! This is worst than I thought. by netsharc · · Score: 3, Insightful

    Is it really the responsibility of anti-virus makers to shield MS's bad programming with a it's-getting-bloatier-all-the-time syntax checker? I mean, it's good for Norton/McAfee that they can live out of MS's dumbness and user ignorance ("I run Norton, and no virus in the world, even the one that just came out today can affect me. A virus definition file, what's that?"), but heck, if you think Norton/McAfee should check everything that is to be sent to the browser, they'll pretty soon have a program as complex as the OS itself, just to check data. I think it's an OS maker's responsibility to build a whole OS, not let Norton/McAfee take care of the other half.

    --
    What time is it/will be over there? Check with my iPhone app!
  13. No "bashing", well-earned untrustworthiness. by jbn-o · · Score: 4, Insightful
    It's a usual bug. All browsers have them.

    No, not all browsers have this bug and so far I can't replicate similar sounding bugs in Mozilla producing a crash and loss of work. Also, not all browsers are so widely used and not all browsers integrate code with widely used e-mail clients (Outlook and Outlook express still use the same HTML renderer that is subject to so many problems). This leads to multiple paths to sabotage someone remotely, perhaps even anonymously. Let's not forget that any application that embeds MSIE/Windows' renderer is vulnerable. Considering how many people use MSIE on MS Windows and how many of them are affected by this bug, I'd hardly call revealing the bug a "joke".

    This bug does *not* exist because MS is Evil.

    I'm not encouraging anyone to think in the false dichotomy of good vs. evil and neither should you. Nobody is helped by glossing over relevant details of how this works or ignoring the wide scope of the bug. This is one of a long string of Microsoft bugs that directly adversely affects ordinary users. We are much better served by suggesting real-world fixes (such as switching to Mozilla to do most browsing, even under a proprietary operating system). We're also better off identifying this exemplar of the practical shortcomings of proprietary software. There's no workaround here--MSIE/Windows users must simply wait for a fix from the proprietor if they won't switch browsers (and any other app adversely affected by embedding the MSIE renderer).

  14. Re:Two points of significance for crashes. by stinky+wizzleteats · · Score: 3, Insightful

    I must admit, there's something strangely fitting about a Microsoft apologist argument based on sheer arrogance.

    It's a usual bug. All browsers have them.

    An oddball javascript gyration that changes colors for the rest of the session is a usual bug. A fundamental HTML rendering flaw that can crash the entire Internet application suite for the world's most popular and profitable operating system is a big deal.

    This bug does *not* exist because MS is Evil

    Agreed. Never attribute to malice that which can be explained by incompetence.

    It doesnt stop anyone to go to serious web sites.

    It will if (as someone else has suggested) the next Melissa-type virus includes a payload to put the bad HTML on your computer and set it as your homepage.

    So much for security by indifference.