User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041019 Firefox/1.0 Michal Zalewsk recently wrote a program that tests for security problems in browsers with malformed HTML fragments. The announcement is at: http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/0 I am not affiliated with Mr. Zalewsk in any way. Reproducible: Always Steps to Reproduce: Two examples cause crashes in Mozilla Firefox, although there may be more: 1) <HTML><INPUT AAAAAAAAAA> 2) <HTML> <HEAD> <MARQUEE> <TABLE> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <TBODY> Attack of the marquees! Actual Results: I have confirmed that both of these malformed input "HTML" files crash the browser. There are probably other semi-random inputs that cause crashes. Expected Results: Even though they are not valid HTML by any stretch of the imagination, Gecko should NOT crash and instead either produce an error message or ignore them. The solution involves two steps. 1) fix the source of these errors (bugs should be filed). 2) Mr. Zalewsk's tool should be used as part of the automated tests to catch other malformed input crashes. Note that there may be issues with image, xul, or other types of input that Mozilla parses. Tools should be developed to test these forms of input against attacks via malformed input. Note that the source of these crashes may be buffer overflows and other defects that may be used to open security holes in the browser. Note that Mr. Zalewsk thinks that the problem "appears to be a memory corruption / overflow problem; TEXTAREA, INPUT, FRAMESET and IMG tags followed by NUL, then a number of extra characters, cause the browser to die while accessing NULL pointer, loop forever, or die while accessing invalid pointer. My guess would be that they calculate tag length using strlen-alike function, but then copy till separator or > - but this is just a guess." Furthermore, Mr. Zalewsk wrote, "The behavior is tag and OS-specific, and is likely exploitable with some luck in those of the cases that do not lead to NULL ptr." I did not confirm Mr. Zalewsk's beliefs regarding the cause of the crashes.
Published on BugTraq, no point in hiding it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Marking as a duplicate of bug 264944. If someone wants to reopen this to address the issue of an 'automated crashing tool', please reopen and give to a better component. *** This bug has been marked as a duplicate of 264944 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Sorry I didn't see bug 264944 when I was searching. I still think that an "automated crashing tool" based on Mr. Zalewsk's code should be considered. I propose reassigning to Product: Webtools, Component: Litmus.
Component: HTML: Parser → Build Config
You need to log in before you can comment on or make changes to this bug.