Workaround for IE "input type crash" bug
It is known that the single line of <input type crash> would crash IE, and this is due to a syntax error induce bug in IE. Try inculding the <body> tag into the page, such as: <html><body><input type crash size=20></body></html> The problem apparently gone.
It is known that the single line of <input type crash> would crash IE, and this is due to a syntax error induce bug in IE.
Try inculding the <body> tag into the page, such as:
<html><body><input type crash size="20"></body></html>
The problem apparently gone.
Try inculding the <body> tag into the page, such as:
<html><body><input type crash size="20"></body></html>
The problem apparently gone.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
To quote some joker from Slashdot.org
Quote:download the patchYou 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.
And the reply
Quote:Do not install this patchI 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?
As a matter of fact all that is needed to crash IE is one line of code:
Code:
Here's some slightly useful information:
Quote:IE tries to compare the type of the input field to "HIDDEN", to see if itshould 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.
And yes, finally, putting a <body> element in fixes it, but an even more sensible solution is to not leave the "type" tag blank.
Quote:download the patchYou 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.
And the reply
Quote:Do not install this patchI 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?
As a matter of fact all that is needed to crash IE is one line of code:
Code:
<input type>
Here's some slightly useful information:
Quote:IE tries to compare the type of the input field to "HIDDEN", to see if itshould 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.
And yes, finally, putting a <body> element in fixes it, but an even more sensible solution is to not leave the "type" tag blank.
