Workaround for IE "input type crash" bug
This is a discussion about Workaround for IE "input type crash" bug in the Windows Software category; 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 in our website and join the conversation
This subject has been archived. New comments and votes cannot be submitted.
May 4
May 4
0
2 minutes
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.
