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.

33 of 887 comments (clear)

  1. OS X IE Is Unaffected by WiseWeasel · · Score: 5, Interesting

    It seems that IE 5.x on MacOS X is not affected by this. Not that it's such a big deal, I imagine any affected Windows versions of IE can be relaunched and people will just avoid going to places with such code. I fail to see the significance. Oh well, glad to see their Mac port is more stable in this regard.

    --
    "I like systems, their application excepted", George Sand (French)
    1. Re:OS X IE Is Unaffected by Anonymous Coward · · Score: 5, Funny

      It seems that IE 5.x on MacOS X is not affected by this.

      I've had it. I'm switching.

  2. mozilla crashes too by Anonymous Coward · · Score: 5, Informative

    I use galeon most of the time and it crashes often too... Just put this in a document

    <body onblur="javascript:self.focus()">

    browse it, and galeon will crash (as of 1.3.3.20030419). Do the same in mozilla, close the browser window, and it will segfault (version 1.3).

    1. Re:mozilla crashes too by arvindn · · Score: 5, Interesting
      Even simpler:

      <script> for(;;){window.open('');} </script>

      Just tried with mozilla 1.2.1: froze.

      OTOH:

      <script> for(;;){} </script>

      If I do this a dialog pops up saying: "A script on this page is trying to screw you. Do you want to kill it?" (not in those words though :)

    2. Re:mozilla crashes too by metalpet · · Score: 5, Interesting

      That's actuallly a good point.
      Everybody who has spent any time developing web pages has learnt that bad (and sometimes even good) html can crash browsers.

      Are we *that* confident in the maturity of our web browsers that causing a browser crash is nowadays considered a serious issue?

      Before jumping the gun on parsing errors that kill the app, it might be smart to go over design errors first (scripts that keeps on going and that bypass the simple "lengthy script" checks are a good example. recursive frameset tricks would qualify too.). I've yet to see a full-featured browser that doesn't choke and/or die when presented with the right mix of recursion, active content and wickedness.

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

  3. Re:Phoenix by thesadjester · · Score: 5, Interesting

    Well, just to note, the Mac OS X version of IE did NOT crash. However, anyone using IE on mac when Camino, Mozilla, and Safari are well put together should have their head examined. Don't forget Opera too.

    The bug seems to be Windows only....so the Mac coders at MS may be better coders...who knows.

    --
    -gabe
  4. bah by chadamir · · Score: 5, Interesting

    people are up in arms over this because it's an ms blunder. It does nothing more than simply halt your browser. As many can testify, halted browsers happen with any of the many browser flavors available.

    I heard someone suggest they hire better testers? How was anyone supposed to test for this. I know this is /. and trolling about MS is ok, but I mean come on, how could anyone see that coming.

    The fact remains though that this crash isn't really that big of a deal. Sure it crashes IE, but it's not like most content webpages want their reader's browsers crashing when they reach the page. Who do we have to worry about? HTML enabled web boards? I have to worry about someone linking c:\con\con as an image everytime I click a link. You just go on with your life. If they are stupid enough to have html enabled then it's their problem, not MS's.

    1. 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
  5. why it crashes by mejh · · Score: 5, Informative

    Just one line is really required:

    According to a post on bugtraq:
    IE tries to compare the type of the input field to "HIDDEN", to see if it
    should be rendered. When there is no type string, a null-pointer is used.
    mshtml.dll calls shlwapi.dll#158 @ 0x636f0037 with a pointer to a static
    unicode string "HIDDEN" and a null-pointer.
    shlwapi.dll#158 does a case-insensitive comparison of two unicode strings:
    it reads from address 0x0 because of the null-pointer and thus causes an
    exception.
    This is not exploitable, other then a DoS because there is no memory mapped
    @ 0x0 and even if you could load something there, you could only compare it
    to "HIDDEN" which gets you nowhere.

  6. Hah! I've got something that will crash IE also.. by [PF]+Lurch · · Score: 5, Interesting
    Ran into this while doing some website design, simplified the problem down to this. Note, the green background is just so you can see the cell a little better.



    <html>
    <head>
    <style>
    .header
    {
    position: fixed;
    background-color: green;
    }
    </style>
    </head>

    <body>
    <table border=1>
    <tr>
    <td class="header">sdf</td><td>sdfsdfsdf</td>
    </tr>
    </body>
    </html>

    You have to mouseover the table cells and you will get a gpf. Should work on IE 5.5 and 6.0.

    note: there is a bogus semicolon after the /td when I preview this post... it shouldn't be there, but I can't get rid of it.

  7. Actually it's just one line by arunkv · · Score: 5, Informative

    Actually only one line of HTML is required:
    <input type>
    As someone on BugTraq already figured out 10 days ago, it's caused due to a null value for the type attribute.

  8. Re:Wonder if that works deeper in a page by zook · · Score: 5, Informative

    I doubt it. From my quick toying around, it seems that if the offending tag appears inside of a tag there's no such effect.

    It's hard to divine the exact fatal combination, of course. :)

  9. Where is this IE you speak of? by westyvw · · Score: 5, Funny

    I have looked all over my computer for this IE thingy you all speak of. I cant find it anywhere. I typed "whereis ie" in the console but nothing turned up. I typed find / -name IE and again nothing. I looked for a man page found none. I clicked on the gear icon thing and looked though the programs installed I dont have it. So I typed apt-get IE. No luck. Must be some obscure piece of software that I cant find. Guess I am better of WITHOUT IT!

  10. Couldn't resist. by jkitchel · · Score: 5, Funny


    Who else couldn't resist from clicking on the link that would crash IE?

  11. Very big deal by fm6 · · Score: 5, Informative
    The IE HTML renderer is actually in a DLL that's shared by several application. And yes, they crash too. It's sort of interesting that that this DLL has no MacOS equivalent. Or perhaps there is an MacOS equivalent, but the usual low-level kludges are different on Mac and Windows.

    Why is this a big deal? Because the largest software company on the planet has no better development practices and safeguards than some half-literate garage hacker.

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

    1. Re:Worth Pointing Out, I Think by Vidiot3k · · Score: 5, Funny

      You might want to get that checked out, I don't think it's healthy to fart bugs.

  13. Re:Hah! I've got something that will crash IE also by Anonymous Coward · · Score: 5, Funny
    note: there is a bogus semicolon after the /td when I preview this post... it shouldn't be there, but I can't get rid of it.
    does IE crash when you use backspace?
  14. 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? ;)

  15. Opera and Mozilla are not affected. by Taco+Cowboy · · Score: 5, Informative



    Tested with the Opera and Mozilla browsers, both on Windoze and Linux platforms, the exploit doesn't affect any of them.


    IE on the other hand, crashed.


    By the way, here is the entire "exploit code":


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







    --
    Muchas Gracias, Señor Edward Snowden !
    1. Re:Opera and Mozilla are not affected. by spectral · · Score: 5, Funny

      And the funny part is, you only need the input line. So therefore putting something like this on your page: <a href="about:<input type die>">Click here</a> to crash IE. will also work. Though it kind of gives it away how it works if you look at the status bar. Too bad /.'s filter won't let me post that link properly. Bleh. :)

  16. I just found what to auto answer to all my spam... by ArcticCelt · · Score: 5, Interesting

    "This HTML also crash Outlook" Sweet, I just found what to auto answer to all my spam. Of course with a subject line that says: I am very interested to buy your products.

    --

    Yahh, hiii haaaaa! -Major Kong, from Dr. Strangelove
  17. Two points of significance for crashes. by jbn-o · · Score: 5, Informative
    I fail to see the significance.

    I see the significance in two ways right now:

    1. No matter what the input stream, the application should not respond by crashing.
    2. If the entire application crashes and the user had something valuable in another window, that data loss could be a big deal. As we become more dependant on web browsing ordinary users type more valuable data into browsers, often without thinking about the need for making backups by entering data in some other place and copying it into the browser.
    1. Re:Two points of significance for crashes. by evilviper · · Score: 5, Funny
      No matter what the input stream, the application should not respond by crashing.

      Man, do I wish someone would tell the Mozilla team that...
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  18. Not THAT serious... by KAMiKAZOW · · Score: 5, Informative

    I made some experiments and this bug is not that serious, if you use IE correctly.
    IE has a feature, Mozilla/Firebird and Opera sadly don't have: IE can run in multiple processes.
    If you open a new window by clicking IExplore.exe instead of pressing Ctrl-N, the new window runs in a seperate process. If you visit that crash page, only the one IE process crashes while the other processes stay unaffected (at least on NT based systems).

    OTOH if a page makes Mozilla crash, the whole app suite goes down. The process seperation with Firebird and Thunderbird is a step into the right direction, but different Firebird windows do still run in a single thread.
    I hope those kind of crashes send a message to all app developers (*cough*OpenOffice.org*cough*), to use multiple processes if possible (at least optional, because that would use more RAM).

  19. This is correct behavior by Christian+Schladetsc · · Score: 5, Funny

    // html_parser.cpp,v (C) 1990- Microsoft #include "html/parser.h" template void html_block(II F, II L) { for (; F != L; ++F) if (tag(*F)()) for (++F; F != L; ++F) if (tag(*F)::Type::val == Type::Crash) __asm int 3; } OK, they didnt use meta-programming C++ techniques, but there's code similiar to that in the IE source. This HTML rudely crashes IE: I didnt make that up. That's the actual contents of the html code that when processed by the HTML parser in IE crashes it. Its safe to look at here, because its not being processed by the parser - its being processed by the text renderer, which just draws text. Read it. Its not hard to understand, even if you've never seen HTML source before. The phrase "input type crash" demonstrates a clear intention, to, um, crash. It was included by the programmers for a number of very good reasons. I dont really care to list them all here. But this is clearly not a "bug". Actually, it shows good engineering practise. Microsoft rox0r. No, really, they do.

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

  21. Wait a minute. by blanks · · Score: 5, Informative

    This makes it on to slashdot, but bugs like this Netscape exploit didn't?

    --
    I deleted my sig years ago.
  22. Re:Aren't you people missing something? by Isofarro · · Score: 5, Informative
    This is a *SPLENDID* way to keep internet exploder (l)users away from webpages.


    Careful - we shouldn't stoop to invalid and non-standard HTML as a means of highlighting abusive and non-standards compliant browsers. So before implementing this, think about validity.

    Obviously, if we wrap this syntax up in a comment, it will be valid HTML. Now, considering Microsoft are stupid enough to implement conditional comments in Internet Explorer, we can wrap things up very nicely:
    <!--[if IE]><input type crash><![endif]-->
    There you go - something which is a valid comment, but MSIE decides to think its something else - like conditional markup.
  23. Careful with those emails! by Anonymous Coward · · Score: 5, Interesting

    I just sent a HTML email with this in to a friend who runs Outlook 2000. As soon as he got it, it crashed Outlook. Funny thing is every time he starts Outlook up it crashes again so he can't rmeove it. Disables his email program with one crafted email!

  24. It did not crash Lynx by drunk_as_in_beer · · Score: 5, Funny

    I repeat, it did not crash Lynx.

    --
    --Drunk as in Beer
  25. NULL pointers and error handling by _xeno_ · · Score: 5, Informative
    Actually, under Windows and UNIX and almost every OS I know about memory location 0 is mapped. It's mapped to the kernel. (Hense the talk of "user space" vs "kernel space".) Attempting to read or write to this location will cause an access violation on the resulting page fault, whatever the OS chooses to call the error. UNIX calls it a segmentation fault, and Windows calls it a general protection fault. (XP calls it "a problem.")

    This is a good thing. NULL is generically used to indicate that a pointer is invalid. Attempting to read or write to a NULL pointer is always a bug and should cause the application to be stopped. Writing and reading from random memory address is a sure fire way to cause interesting results. Enforcing such restrictions helps to force programmers to ensure their programs are at least less buggy in that respect.

    MacOS 9 allowing location 0 read/write is a bug, not a feature. (Well... probably not, really. MacOS 9 and prior probably allowed 0 as a valid userspace location.) When a program attempts to read or write to NULL, it should be terminated, as this is an error condition. This would be like ignoring the low oil pressure light on your car - you might be able to keep running for a while, but disaster could strike further down the road.

    --
    You are in a maze of twisty little relative jumps, all alike.
  26. Re:Inquirer says one line by norweigiantroll · · Score: 5, Funny

    <input type crash>
    It's not a bug, it's a feature! The "crash" input type allows the user to crash the browser. It's very useful and another Microsoft (TM) innovation.