Closed Bug 265115 Opened 20 years ago Closed 20 years ago

Crash due to malformed HTML/automated crashing tool should be used in testing

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 264944

People

(Reporter: jfcst24, Unassigned)

References

(
URL
)

Details

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.
Group: security
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
Closed: 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.