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.

17 of 887 comments (clear)

  1. Inquirer says one line by A+nonymous+Coward · · Score: 4, Informative
  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).

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

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

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

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

  7. Re:Phoenix by bockman · · Score: 4, Informative
    Well, phoenix (0.5) crashes on my machine (Debian) in many ways, often downloading stuff. A couple of times, in not yet determined situations, it started to eat all memory, making the kernel to swap furiously until I killed phoenix threads.

    Nothing wrong with that, Phoenix being still an alpha product. But please do not compare it with mature products, even if they are from Microsoft.

    Also I don't understand why there are so many threads when nothing is going on (no download in progress and a single page shown).

    --
    Ciao

    ----

    FB

  8. 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 !
  9. 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 blibbleblobble · · Score: 4, Informative
      "Got a current example? [of mozilla crashing]"

      Yep. GNU/Linux/Windowmaker, visiting pages containing java, on a machine at best unfamiliar with the language.
      ps -a
      14472 java-vm [defunct]
      14475 java-vm
      14476 java-vm
      14479 java-vm
      ... etc
  10. 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).

  11. 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.
  12. 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.
  13. Re:Worth Pointing Out, I Think by cscx · · Score: 4, Informative

    What's most interesting about this is after the "crash/error/send error report" dialog pops up, I get a small message box that says "IE has encountered an error and will need to close. Click OK to do so." However, if you don't click OK you still have complete use of the browser. I am submitting this in IE after having clicked the "crash" link on the front page.

  14. I got a fix... by miketang16 · · Score: 4, Informative

    http://www.w3c.org

    nuff said.

    --
    -------
    "In times of universal deceit, telling the truth becomes a revolutionary act."
    -- George Orwell
  15. 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.
  16. Re:Careful with those emails! by netsharc · · Score: 4, Informative

    That sucks. :) Better find the Outlook.pst file (%HOME%\Application Data\Microsoft something something), which has all the data Outlook shows. Rename that file temporarily, start Outlook (it'll probably create a blank PST file), turn off the Preview Pane/AutoPreview, close Outlook and replace the new PST file with a copy of the original one. Hopefully you can then start Outlook with the Preview Pane turned off. Of course, this may not work when Outlook stores the Preview Pane settings inside the PST file itself. When that's the case, you can always go back to the previous method, but don't close Outlook and instead try to open the old PST file (Right click on "Outlook Today - [Personal Folders]" on the Folders List and choose "Open Outlook Data File...").

    Hey why am I bothering, you are AC and probably won't see this anyway.

    --
    What time is it/will be over there? Check with my iPhone app!