HTML Rendering Crashes IE 1000
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.
Inquirer says one line (Score:5, Informative)
Re: (Score:3, Informative)
Re:Inquirer says one line (Score:5, Insightful)
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.
Re:Inquirer says one line (Score:4, Interesting)
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.
Re:Inquirer says one line (Score:5, Funny)
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.
Wonder if that works deeper in a page (Score:5, Funny)
Re:Wonder if that works deeper in a page (Score:5, Informative)
It's hard to divine the exact fatal combination, of course.
Re:Wonder if that works deeper in a page (Score:3, Interesting)
just putting "about:<input type crash>" in the url bar already worked...
which is just 1 line
Re:Wonder if that works deeper in a page (Score:3, Informative)
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">
Re:Wonder if that works deeper in a page (Score:3, Interesting)
If it does, I can imagine many people posting malicious links in blogs everywhere by the end of the day.
Re:Wonder if that works deeper in a page (Score:3, Informative)
OS X IE Is Unaffected (Score:5, Interesting)
So is IE 5.1.6 on OS 9.XX (Score:3, Funny)
Re:So is IE 5.1.6 on OS 9.XX (Score:5, Insightful)
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.
NULL pointers and error handling (Score:5, Informative)
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)
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.
Re:OS X IE Is Unaffected (Score:5, Funny)
I've had it. I'm switching.
Two points of significance for crashes. (Score:5, Informative)
I see the significance in two ways right now:
Re:Two points of significance for crashes. (Score:5, Funny)
Man, do I wish someone would tell the Mozilla team that...
Re:Two points of significance for crashes. (Score:5, Insightful)
Man, do I wish someone would tell the Mozilla team that...
Got a current example?
Re:Two points of significance for crashes. (Score:5, Informative)
Yep. GNU/Linux/Windowmaker, visiting pages containing java, on a machine at best unfamiliar with the language.
Re:Current example Mozilla crash (Score:3, Informative)
Re:Two points of significance for crashes. (Score:5, Funny)
Only in the same sense that the Sports Illustrated football phone is free.
Re:Two points of significance for crashes. (Score:3, Interesting)
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!
No "bashing", well-earned untrustworthiness. (Score:5, Insightful)
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".
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 [mozilla.org] 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).
Re:Two points of significance for crashes. (Score:4, 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.
Users should not have to browse warily. (Score:5, Insightful)
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.
Re:OS X IE Is Unaffected (Score:5, Funny)
Re:OS X IE Is Unaffected (Score:3, Informative)
Re:OS X IE Is Unaffected (Score:3, Funny)
Re:OS X IE Is Unaffected (Score:5, Insightful)
So hold your chickens before they jump the conclusion.
MSFT Mac Apps (Score:3, Informative)
Somewhat. When it comes to Office, I prefer the Mac versions to those for Windows. Perhaps it's because MS had some extra time in bringing the Mac versions to market. (MS Mac Office 98 / MS Windows Office 97.... MS Mac Office 2001 / MS Windows Office 2000.... Office v.X for OS X doesn't really count as it's a hybrid of Office 2001 and Office XP). The look and feel seems easier to l
Re:MSFT Mac Apps (Score:5, Funny)
- Windows Media Player for the Mac (they need a better name for that app) works, but feels like quick and dirty port...
No big surprise, it feels that way under Windows as well.mozilla crashes too (Score:5, Informative)
<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).
An infinite loop is not a bug in the application (Score:3, Interesting)
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)
Re:Bugs, crashes (Score:3, Funny)
Nah, it's a feature, man! It prevents IE users from seeing non-Microsoft-certified websites!
Re:Crashing != bug (Score:5, Insightful)
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.
Re:An infinite loop is not a bug in the applicatio (Score:3, Insightful)
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,
Re:mozilla crashes too (Score:5, Interesting)
<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 :)
Re:mozilla crashes too (Score:5, Interesting)
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>
Re:mozilla crashes too (Score:5, Insightful)
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.
IE has become a standard part of the Windows OS. As more and more applications use it, the impact of crashing greatly increases.
Re:mozilla crashes too (Score:5, Funny)
Give it up for the Halting Problem Solution. Whoo whoo!
Time to recognize a wider social significance. (Score:3, Insightful)
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
download the patch (Score:5, Funny)
Please note that this is a pretty bloated patch, but well worth it. ;)
Do Not Download this patch! (Score:5, Funny)
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?
No bugs here (Score:4, Funny)
input type _____ (Score:3, Funny)
input type giveBoBathan$1,000,000USD
Unfortunatly, Microsoft must have known of this potential exploit.
--Travis
Re:input type _____ (Score:4, Funny)
bah (Score:5, Interesting)
I heard someone suggest they hire better testers? How was anyone supposed to test for this. I know this is
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)
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)
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)
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)
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?
Hah! I've got something that will crash IE also.. (Score:5, Interesting)
<html>
<head>
<style>
{
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
Re:Hah! I've got something that will crash IE also (Score:5, Funny)
confirmed: the crash happens (Score:3, Informative)
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...)
Actually it's just one line (Score:5, Informative)
<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].
Where is this IE you speak of? (Score:5, Funny)
Pretty simple bug really (Score:4, Interesting)
So.... (Score:4, Insightful)
Slow news night, eh?
Re:So.... (Score:5, Insightful)
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? ;)
Light-weight alright ;o) (Score:3, Interesting)
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>
<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
Couldn't resist. (Score:5, Funny)
Who else couldn't resist from clicking on the link that would crash IE?
Worth Pointing Out, I Think (Score:5, Insightful)
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.
Re:Worth Pointing Out, I Think (Score:5, Funny)
Re:Worth Pointing Out, I Think (Score:5, Informative)
What I really want to see... (Score:5, Funny)
Write a worm.... (Score:3, Interesting)
I just found what to auto answer to all my spam... (Score:5, Interesting)
Get the Fix! (Score:4, Funny)
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)
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).
This is correct behavior (Score:5, Funny)
Wait a minute. (Score:5, Informative)
OSS and the w3 falling behind - AGAIN! (Score:5, Funny)
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)
nuff said.
Careful with those emails! (Score:5, Interesting)
Re:Careful with those emails! (Score:3, Funny)
Re:Careful with those emails! (Score:5, Informative)
Hey why am I bothering, you are AC and probably won't see this anyway.
It crashes with other input "types" (Score:3, Informative)
<html>
<form>
<input type abc123>
</form>
</html>
input type crash (Score:4, Funny)
Re:Phoenix (Score:5, Interesting)
The bug seems to be Windows only....so the Mac coders at MS may be better coders...who knows.
Re:Phoenix (Score:5, Informative)
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).
Use a fresher Phoenix (Score:3, Insightful)
Re:Phoenix (Score:3, Flamebait)
No offense, but many Alpha-products are perfectly comparable to ultra-mature Microsoft products like IE or MSOffice.
Especially Phoenix/Firebird/Mozilla-Browser/whateveritscalled now which is very stable at least on my installation.
Opera and Mozilla are not affected. (Score:5, Informative)
Tested with the Opera and Mozilla browsers, both on Windoze and Linux platforms, the exploit [vibrantlogic.com] 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>
Re:Opera and Mozilla are not affected. (Score:5, Funny)
Re:Opera and Mozilla are not affected. (Score:3, Informative)
Re:Opera and Mozilla are not affected. (Score:5, Funny)
IE is doing exactly what the tag is telling it to do. It's a feature, not a bug!
Re:I tried with Opera (Score:3, Funny)
It did not crash Lynx (Score:5, Funny)
no prob with Konqueror (Score:3, Interesting)
Re: (Score:3, Informative)
No (Score:3, Informative)
I cannot confirm my self... now Windows machines here...
what happens? (Score:3, Interesting)
Re:what happens? (Score:5, Funny)
That's why he freaks out sometimes and starts screaming DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS!!
Re:IE on OS X ok (Score:3, Informative)
Yes, I'd even go as far as to say they re-wrote the rendering engine from the ground up. PS MacOS 9 is safe too.
Re:Aren't you people missing something? (Score:5, Informative)
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 [microsoft.com], we can wrap things up very nicely:There you go - something which is a valid comment, but MSIE decides to think its something else - like conditional markup.
Re:A new way... (Score:3, Informative)
No, the specification says you need a body element or a frameset element, you don't need to use a tag to create an element though.
The following is a valid HTML 4.01 Strict document, feed it in to the validator [w3.org] if you want conformation.
Re:Whoa! This is worst than I thought. (Score:4, Insightful)