Slashdot Log In
HTML Rendering Crashes IE
Posted by
michael
on Sat May 03, 2003 02:42 AM
from the tough-job dept.
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Inquirer says one line (Score:5, 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.
Parent
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.
Parent
OS X IE Is Unaffected (Score:5, Interesting)
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.
Parent
Re:OS X IE Is Unaffected (Score:5, Funny)
I've had it. I'm switching.
Parent
Two points of significance for crashes. (Score:5, Informative)
I see the significance in two ways right now:
Parent
Re:Two points of significance for crashes. (Score:5, Funny)
Man, do I wish someone would tell the Mozilla team that...
Parent
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?
Parent
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.
Parent
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.
Parent
Re:OS X IE Is Unaffected (Score:5, Funny)
Parent
Re:OS X IE Is Unaffected (Score:5, Insightful)
So hold your chickens before they jump the conclusion.
Parent
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.Parent
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.
Parent
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).
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 :)
Parent
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>
Parent
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.
Parent
Bugs, crashes (Score:5, Insightful)
Parent
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?
Parent
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.
Parent
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.
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)
Parent
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)
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)
Parent
Re:Worth Pointing Out, I Think (Score:5, Informative)
Parent
What I really want to see... (Score:5, Funny)
I just found what to auto answer to all my spam... (Score:5, Interesting)
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:Phoenix (Score:5, Interesting)
The bug seems to be Windows only....so the Mac coders at MS may be better coders...who knows.
Parent
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).
Parent
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>
Parent
Re:Opera and Mozilla are not affected. (Score:5, Funny)
Parent
It did not crash Lynx (Score:5, Funny)
Parent
Re:what happens? (Score:5, Funny)
That's why he freaks out sometimes and starts screaming DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS!!
Parent
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? ;)
Parent
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.
Parent