Forgot your password?
typodupeerror
Internet Explorer The Internet Bug

HTML Rendering Crashes IE 1000

Posted by michael
from the tough-job dept.
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.
This discussion has been archived. No new comments can be posted.

HTML Rendering Crashes IE

Comments Filter:
  • by A nonymous Coward (7548) * on Saturday May 03, 2003 @03:46AM (#5867850)
    Here is their story [theinquirer.net]
    • by MrP- (45616) *
      They're wrong, at least with my ver of IE, you have to have the FORM tag also or it just displays a text input box
      • by Selanit (192811) on Saturday May 03, 2003 @05:20AM (#5868097)
        I just crashed my copy of IE (5.00.2614.3500) with no more than <input type crash>.

        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.
        • by craigeyb (518670) on Saturday May 03, 2003 @11:37AM (#5868900) Homepage

          Not to be overly trollish here, but you could also squish poetry onto one long line or a big novel onto one really huge page, like something in Guinness's Book of World Records I suppose.

          The point is, we use line counts in computer languages, even though most computer languages can be spaced out in numerous ways, because it provides a good rough estimate of length and complexity. It's not always the best metric, but oftentimes it serves its purpose well. In this case, the typical slashdot reader can see that the exploit is only "five lines" and realize that it's not a overly complicated HTML parser exploit but instead something ridiculously simple.

        • by norweigiantroll (582720) on Saturday May 03, 2003 @12:28PM (#5869112)
          <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.
  • by ShieldW0lf (601553) on Saturday May 03, 2003 @03:46AM (#5867852) Journal
    Could wreak havoc in html-enabled forums
    • by zook (34771) on Saturday May 03, 2003 @04:00AM (#5867921)
      I doubt it. From my quick toying around, it seems that if the offending <input> tag appears inside of a <body> tag there's no such effect.

      It's hard to divine the exact fatal combination, of course. :)
    • actually it could indeed...

      just putting "about:<input type crash>" in the url bar already worked...

      which is just 1 line
      • Make it shorter. Just type
        about:<input type>
        in the url bar and IE crashes.

        The important thing is to leave the value of type attribute undefined.

        For example, this works too:
        about:<input with sans-serif type "ALL YOUR BASE ARE BELONG TO US">

  • by WiseWeasel (92224) on Saturday May 03, 2003 @03:47AM (#5867853)
    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.
    • Heh. Thank you so much for porting a better IE to the Mac, Billy...
      • by b1t r0t (216468) on Saturday May 03, 2003 @09:03AM (#5868464)
        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.

        • by _xeno_ (155264) on Saturday May 03, 2003 @11:51AM (#5868954) Homepage Journal
          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.

    • Very big deal (Score:5, Informative)

      by fm6 (162816) on Saturday May 03, 2003 @04:17AM (#5867982) Homepage Journal
      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.

    • by Anonymous Coward on Saturday May 03, 2003 @05:17AM (#5868091)
      It seems that IE 5.x on MacOS X is not affected by this.

      I've had it. I'm switching.
    • by jbn-o (555068) <mail@digitalcitizen.info> on Saturday May 03, 2003 @05:27AM (#5868118) Homepage
      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.
      • by evilviper (135110) on Saturday May 03, 2003 @06:47AM (#5868232) Journal
        No matter what the input stream, the application should not respond by crashing.

        Man, do I wish someone would tell the Mozilla team that...
      • Re potential for Outlook crashing, I'm not going to try this but if an outlook user receives an email containing this HTML then as soon as they view the email, Outlook crashes right?

        But the email would still be in their Inbox... so the next time they start outlook... oh just rememebered, Outlook Express (not sure about the full Office Outlook version) will not display an email after a crash.

        Worrying though!
    • by jbn-o (555068) <mail@digitalcitizen.info> on Saturday May 03, 2003 @07:16AM (#5868282) Homepage
      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 should have included the following in my first response to your rather overrated and glib point above: Users won't know where to avoid going until it is too late.

    • by jmauro (32523) on Saturday May 03, 2003 @08:29AM (#5868395)
      IE's rendering engine on the Mac is completely different than the rendering engine on Windows. The MS Mac team did a great job re-implementing the entire engine. Now if they'd only port Mac IE to Windows I'd be happy.
    • From what I've read, IE for Mac doesn't share any code from its Windows counterpart. In fact, I've read that the Mac Business Unit doesn't get much assistance at all from the Windows developers at MS.
    • See? You mac people just keep proving me right - macs just don't have all the features that Windows machines do!
  • mozilla crashes too (Score:5, Informative)

    by Anonymous Coward on Saturday May 03, 2003 @03:47AM (#5867858)
    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).
    • It's a bug in the document.

      What happens I guess is:

      1. You move the mouse outside the body to an image or off window.
      2. That blurs it.
      3. It wants focus, but the mouse is off the window.

      Somewhere javascript is point to self, so it runs focus, but the mouse is not on an object with any relation to javascript.

      This one may just be on the boundary between what is and what isn't.
      • Bugs, crashes (Score:5, Insightful)

        by fm6 (162816) on Saturday May 03, 2003 @06:09AM (#5868183) Homepage Journal
        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.
        • Nah, it's a feature, man! It prevents IE users from seeing non-Microsoft-certified websites!

      • It's a bug in the document.

        No, if that does indeed crash an application it's a bug (and I'll assume, for the sake of argument, that the parent is correct even though other posters have stated they can't get Mozilla to crash from this). Applications should not respond to any input by crashing and applications should give the user a chance to lose data because someone on the net essentially (perhaps inadvertantly) instructed the application to crash.

        I appreciate the logic of the loop you're describing,

    • by arvindn (542080) on Saturday May 03, 2003 @05:22AM (#5868106) Homepage Journal
      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 :)

      • by metalpet (557056) on Saturday May 03, 2003 @06:22AM (#5868202) Journal
        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>
        • by JimDabell (42870) on Saturday May 03, 2003 @06:57AM (#5868249) Homepage

          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.

        • Of course any attempt to pass that as a security concern back then would have been laughed at. loudly.

          And undeservedly. People who could not see the potential for the web and understand that a critical application like a web browser must be made crash-proof should be corrected. Not by pointing and laughing, but by careful and patient explanation about how more people in everyday society depend on a well-functioning web browser that can handle any input (including input from potentially hostile webpage

  • by mraymer (516227) <mraymer AT centurytel DOT net> on Saturday May 03, 2003 @03:49AM (#5867869) Homepage Journal
    You can download the patch to this bug here: www.mozilla.org [mozilla.org]

    Please note that this is a pretty bloated patch, but well worth it. ;)

    • by gad_zuki! (70830) * on Saturday May 03, 2003 @05:11AM (#5868078)
      I just installed this bloated patch and it has caused nothing but problems:

      1. All of my x10 ads are missing. I would like to remain up to date on the advances in wireless webcam technology and x10's implied use on spying on girls without their consent.

      2. There is a *major* bug that hides webpages behind other webpages. I found a half-ass fix for now: click on the "tabs" at the top.

      3. This patch broke both Comet Cursor and Hotbar. Worse, they're not auto-installing when I visit certain webpages or when I click on my co-workers "Upgrade Outlook for colors and background" emails.

      4. My script debugging isn't working anymore. Sure, I have no idea what all that techno-babble means, but I know its broken!

      5. Where the heck is msn.com now?
  • by Fastball (91927) on Saturday May 03, 2003 @03:50AM (#5867874) Journal
    There no bugs here. The infidels are committing suicide on the logic gates of ActiveX. Lies! The stupid infidels...
  • by BoBathan (166436) * <.ten.emohtfos. .ta. .nahtabob.> on Saturday May 03, 2003 @03:51AM (#5867876) Homepage Journal
    Seconds after reading this, I tried this out on my own, slightly modified.

    input type giveBoBathan$1,000,000USD

    Unfortunatly, Microsoft must have known of this potential exploit. :(

    --Travis
  • bah (Score:5, Interesting)

    by chadamir (665725) on Saturday May 03, 2003 @03:55AM (#5867899) Homepage
    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.
    • Re:bah (Score:5, Insightful)

      by gerardrj (207690) on Saturday May 03, 2003 @04:09AM (#5867953) Journal
      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.
    • Re:bah (Score:4, Informative)

      by nordicfrost (118437) * on Saturday May 03, 2003 @06:07AM (#5868178)
      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.
      I (have to (it's a app made for the MS version of java)) use IE for inputting data to the web publishing system at work. I also like to have more than one window open and surf around while researching stories. I have encountered lots and lots of annoying IE errors that either crashes the app or renderes it unsuable. When that happens, I risk losing my work unless I save it whenever I do anything else with the browser. That is really annoying, that is why I don't like IE.
  • why it crashes (Score:5, Informative)

    by mejh (564536) on Saturday May 03, 2003 @03:57AM (#5867902)
    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.
    • Re:why it crashes (Score:3, Informative)

      by frisket (149522)
      When there is no type string, a null-pointer is used.

      There's the bug. When TYPE is absent, the default is the value "TEXT". This is in the HTML spec, and in the DTD, but as I said earlier, browser makers don't read doc. It should only compare the value to HIDDEN if a value has been specified.

      Handling default values is something most 12-year-old programmers can master. Why do some browser makers fail to do it right?

  • by [PF] Lurch (47956) on Saturday May 03, 2003 @03:58AM (#5867906) Journal
    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.

    • by Anonymous Coward on Saturday May 03, 2003 @04:42AM (#5868025)
      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?
    • by Anonymous Coward
      Using IE6 on WinXP prof. with all SPs and updates installed.

      IE version: 6.0.2800.1106.xpsp2.021108-1929

      but I cannot see any obvious reason, WHY this happens. and WHY this only happens, when you put the mouse over the cell...

      actually a bit mysterious to me

      (Also checked: Mozilla 1.4a renders this page fine and has no problems with the mouse hovering over the cells. Again, mysterious, eeeeh...)
  • by arunkv (116142) <slashdot@nOSpAm.element77.com> on Saturday May 03, 2003 @03:58AM (#5867910) Homepage
    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 [securityfocus.com].
  • by westyvw (653833) on Saturday May 03, 2003 @04:02AM (#5867928)
    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!
  • by JanusFury (452699) <kevin.gadd@gm[ ].com ['ail' in gap]> on Saturday May 03, 2003 @04:04AM (#5867934) Homepage Journal
    If you skip over the assembly instruction that causes the exception in a debugger, everything works fine. So if anyone pulls this trick on you, just open the debugger and skip the instruction. :) That, or get a better browser.
  • So.... (Score:4, Insightful)

    by The Bungi (221687) <thebungi@gmail.com> on Saturday May 03, 2003 @04:04AM (#5867935) Homepage
    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?

    • Re:So.... (Score:5, Insightful)

      by zook (34771) on Saturday May 03, 2003 @04:43AM (#5868027)
      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? ;)

  • by maharg (182366) on Saturday May 03, 2003 @04:09AM (#5867950) Homepage Journal
    The error is invalid page fault in shlwapi.dll

    DLL Name: Shell Light-weight Utility
    Library Description: Contains utility functions for handling paths, urls, strings, registry entries and color settings

    Interesting that this dll can also 'handle' registry entries....

    In fact, the 5 lines of html can be reduced down to one:

    <input type>

    ..although placing this in the middle of a page doesn't always work:

    <html>
    <head>
    <title>foo</title>
    </head>
    <body>
    <h1>foo</h1>
    <input type>
    </body>
    </html>

    type seems to be the only attribute that has the desired effect
  • by jkitchel (615599) <jacob_kitchel AT hotmail DOT com> on Saturday May 03, 2003 @04:10AM (#5867959)

    Who else couldn't resist from clicking on the link that would crash IE?
  • by coloth (630330) on Saturday May 03, 2003 @04:32AM (#5868011)
    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.

  • by weave (48069) on Saturday May 03, 2003 @04:57AM (#5868054) Journal
    I want to see some simple HTML code that will crash a spammer's email harvesting web crawler. Now THAT would be "News.*that matters..."
  • Write a worm.... (Score:3, Interesting)

    by clambake (37702) on Saturday May 03, 2003 @04:58AM (#5868057) Homepage
    Write a worm that sets everyone's home-page to this... so very evil.
  • by ArcticCelt (660351) on Saturday May 03, 2003 @05:06AM (#5868068)
    "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.
  • by DarkHelmet (120004) <[mark] [at] [seventhcycle.net]> on Saturday May 03, 2003 @05:43AM (#5868145) Homepage
    Windows Update:

    BugFix Q3823982

    This patch solves a vulnerability with Microsoft Internet Explorer Versions 4.0, 5.0, 5.5 and 6.0. A missing validation allowed snippits of code such as <form><input type cras.....

    -----

    This program has had a critical error and must be shut down...

  • Not THAT serious... (Score:5, Informative)

    by KAMiKAZOW (455500) <kamikazow@hotmail.com> on Saturday May 03, 2003 @05:54AM (#5868163)
    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).
  • by Christian Schladetsc (645031) on Saturday May 03, 2003 @06:01AM (#5868171) Journal
    // 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.
  • Wait a minute. (Score:5, Informative)

    by blanks (108019) on Saturday May 03, 2003 @06:28AM (#5868209) Homepage Journal
    This makes it on to slashdot, but bugs like this Netscape exploit [sina.com] didn't?
  • by IIRCAFAIKIANAL (572786) on Saturday May 03, 2003 @09:22AM (#5868499) Journal
    I mean, IE implements the <input type crash> tags correctly and you all just noticed? Yet again we see that Microsoft IE is ahead of the game, implementing useful tags that the w3 hasn't even thought of yet.

    Why is it that Microsoft is saddled with the burden of creating useful standards? Isn't this supposed to be the job of the w3?

    I expect we'll have to wait a few years to see it in Moz and by then, microsoft will have implemented <input type explode into tiny pieces> or something even more spectacular.
  • I got a fix... (Score:5, Informative)

    by miketang16 (585602) on Saturday May 03, 2003 @09:34AM (#5868520) Journal
    http://www.w3c.org [w3c.org]

    nuff said.
  • by Anonymous Coward on Saturday May 03, 2003 @09:54AM (#5868560)
    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!
    • Is he still your friend?
    • by netsharc (195805) on Saturday May 03, 2003 @12:15PM (#5869045)
      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.
  • by rollingcalf (605357) on Saturday May 03, 2003 @10:47AM (#5868715)
    You don't need to specifically put "input type crash", as something like this also crashes IE:

    <html>
    <form>
    <input type abc123>
    </form>
    </html>
  • by cyclist1200 (513080) on Saturday May 03, 2003 @09:46PM (#5871927) Homepage
    Finally, software that does what it's told!

There is no distinction between any AI program and some existent game.

Working...