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.
Here is their story
Infuriate left and right
Could wreak havoc in html-enabled forums
-1 Uncomfortable Truth
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)
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).
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
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
EOF
Comment removed based on user account deletion
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.
/. and trolling about MS is ok, but I mean come on, how could anyone see that coming.
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.
NJ Local Music Scene
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.
<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
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.
Comment removed based on user account deletion
Heh. Thank you so much for porting a better IE to the Mac, Billy...
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!
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.
using namespace slashdot;
troll::post();
Slow news night, eh?
Who else couldn't resist from clicking on the link that would crash IE?
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.
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
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
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 !
Unfortunately, 0.5 is very old and there are only nightly releases since then. Try the nightly build from March 20th. It haven't managed to crash it once in those weeks.
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..."
"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
Do you ever notice that when Microsoft makes a Mac version of a piss-poor Windows product that it tends to not suck [as much]?
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 live with and the Entrouage email/calendar/pim app is a lot more sane than Outlook (though is lacking full Excange integration).
MSN Messenger for the Mac is a pretty smooth little app... single file to deal with and none of the virus-like atributes of the Windows version.
MS IE for Mac was pretty good back in the days of Netscape 4. But these days there are MUCH better choices for Mac users.
Windows Media Player for the Mac (they need a better name for that app) works, but feels like quick and dirty port... I wouldn't be surprised if it wasn't done by the MS MBU (Macintosh Business Unit -- MS's Mac software team located in the Silicon Valley).
I see the significance in two ways right now:
Digital Citizen
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...
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
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).
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.
This makes it on to slashdot, but bugs like this Netscape exploit didn't?
I deleted my sig years ago.
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:There you go - something which is a valid comment, but MSIE decides to think its something else - like conditional markup.
Those sneaky bastards must have QA'd that piece of code. How can MS really compete with that?
Yes, I am an agent of Satan, but my duties are largely ceremonial.
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...)
I mean, IE implements the 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.
Robots are everywhere, and they eat old people's medicine for fuel.
http://www.w3c.org
nuff said.
-------
"In times of universal deceit, telling the truth becomes a revolutionary act."
-- George Orwell
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!
I repeat, it did not crash Lynx.
--Drunk as in Beer
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.
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.
Is it really the responsibility of anti-virus makers to shield MS's bad programming with a it's-getting-bloatier-all-the-time syntax checker? I mean, it's good for Norton/McAfee that they can live out of MS's dumbness and user ignorance ("I run Norton, and no virus in the world, even the one that just came out today can affect me. A virus definition file, what's that?"), but heck, if you think Norton/McAfee should check everything that is to be sent to the browser, they'll pretty soon have a program as complex as the OS itself, just to check data. I think it's an OS maker's responsibility to build a whole OS, not let Norton/McAfee take care of the other half.
What time is it/will be over there? Check with my iPhone app!
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 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).
Digital Citizen
5.50.4134.0600
Type address
about:<input type crash>
and watch IE go up in smoke
IEXPLORE caused an invalid page fault in
module SHLWAPI.DLL at 016f:70bd1d1e.
Registers:
EAX=00000001 CS=016f EIP=70bd1d1e EFLGS=00010202
EBX=01b9bf20 SS=0177 ESP=0279fa00 EBP=0279fa10
ECX=0279fa18 DS=0177 ESI=00000000 FS=138f
EDX=70d4b0a8 ES=0177 EDI=00000000 GS=0000
Bytes at CS:EIP:
0f b7 06 46 46 83 f8 41 7c 05 83 f8 5a 7e 1d 0f
Stack dump:
70e7f5b0 70e4e2e2 00000000 70d4b0a8 00000034 70c93150 00000000 00000034 01ba6148 01b9b1d0 01b9bf20 01ba6148 01ba6148 70c9300b 00000034 01ba6148
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
Finally, software that does what it's told!