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.
Here is their story
Infuriate left and right
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).
Comment removed based on user account deletion
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.
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
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.
I cannot confirm my self... now Windows machines here...
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]?
;-)
Of course I'm not saying that I use Mac IE, but if it came down to using IE and gnawing my own leg off, I'd still have two legs at a Mac.
------------ Ben Chroneos
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.
The "crash" part is just for looks. It would still crash with
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
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 !
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
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).
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.
This makes it on to slashdot, but bugs like this Netscape exploit didn't?
I deleted my sig years ago.
It still barfs, and it barfs in a slightly different color, but less often. Experiment with nightlies. When you find one that doesn't barf too often, go with it.
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.
Opera 7.10 on Win 2k just gave a blank page leaving the other pages up and running no matter what identification I set it to.
Cuiusvis hominis est errare; nullius nisi insipientis in errore perseverare.
In the aim of experimentation, I looked this up on the W3C HTML 4 pages. OK, so IE isn't usually one for sticking to the standards, but bear with me here... /.ism below
here is the bit distilled into
INPUT
type (implied) one from text|password and so on
if type is not present, text should be assumed. (This explains why everything renders it as a textbox, at least)
In the code that kills IE, the type attribute is present but not set, so its quite feasible that other browsers check for the type value in a different method, like assuming it is text unless the attribute value is in the list of valid types.
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.
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">
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
Last time I checked I could still crash Mozilla with onSelect="select()" or an onFocus="select()" in a <textarea>.
They all have bugs to some point. You're a fool if you think otherwise.
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...)
Think before you bash.
Ofcourse Mozilla has bugs. So has Opera, Konquerour and Safari, hell, maybe even Lynx have its flaws.
The point is that about 95% of all Internet users browse with MSIE v5+, which makes this a pretty critical bug (and possible exploit)
-smurk
BTW, the above link does not make use of the about-link method to inject the malicious code. Slashcode filters attempts to use about: in links and IE does not follow redirects to the about: protocol. Also the most well known URL obfuscating redirector, http://yahoo.com?http://host/foo/bar.html, won't redirect to about: anyway. The script which is addressed by the above URL does not filter the URL data which it then uses in the redirection announcement. It's not my script or webserver, and if I had taken proper precautions, that link would not be traceable to me. It is also possible to further obfuscate the target by chaining it with the yahoo redirector: bye bye. With this method, anyone who knows the URL of an amateurish script like the one mentioned above, can post "killer-links" to message boards.
http://www.w3c.org
nuff said.
-------
"In times of universal deceit, telling the truth becomes a revolutionary act."
-- George Orwell
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 if you want conformation.
You don't need to specifically put "input type crash", as something like this also crashes IE:
<html>
<form>
<input type abc123>
</form>
</html>
---------
There is inferior bacteria on the interior of your posterior.
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.
The 1,3 version seems to fix all the ebay crash problems.
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!
As of IE6SP1, the about: protocol is disabled, and this no longer works (you can still get it, of course, by going to a page).
You need some reading comprehension skills. He meant that in ADDITION to IE.
Conglom-O: We Own You (TM).
Gotta call you on this one because you're talking out your ass.
It's obvious you don't understand how the operating systems handle memory on MacOS, MacOS X, and Windows NT/2K/XP.
First of all when something says NULL, it does not always mean zero. It's true that many systems use zero as an alias for NULL, but NULL can be defined as anything (read your C/C++ language definitions... that's why that have something called null and NULL defined.)
Secondly, Mac OS is not a protected memory operatating system. So yeah, it will let you write to any address you give it. WHICH IS VERY VERY BAD. It will let you write to the memory space whether or not you own it. And it's the reason why Mac OS when it crashes, crashes hard.
However, attempting to read from or write to NULL even on Mac OS will cause it to terminate your program. It's not valid to access the NULL identifier.
In Windows and Mac OS X, where protected memory is implemented... it will generate a Segmentation Fault for trying to access memory outside of your program and thus terminate your program.
If you really want to see how fast you can crash a Mac by writting to null this simple C program will demonstrate:
int main(int argc, char** argv)
{
int *a;
a = (int*)NULL;
*a = 5;
return 0;
}
And it's not explorer itself that causes the crash on Windows, it's a specific DLL it's accessing, SHLWAPI.DLL. I imagine whatever the Mac version of Explorer uses in it's place is implemented correctly. So go read the RTFA yourself, then go read some books on Computer and OS architecture before you make a post about something you don't understand again, because I'm sure a lot of people are nodding their heads at you saying "yeah, that makes sense." when its a bunch of BS.
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
The semicolon is from Slashdot breaking your & g t ; apart, to ensure that it properly line wraps.
They still insist that breaking apart &blah; tags is not a bug.
I am unamerican, and proud of it!
this alone yields the same result (in IE 6.0.2800.1106.xpsp1.020828-1920, at least):
<table border="1">
<tr>
<td style="position: fixed;"></td><td></td>
</tr>
</table>
it looks like the table border must be >0, but only because the crash actually occurs when you mouse-over (any part of) the border, not the cell itself. weird.