396572 - Firefox 2.0.0.6/7 crash opening a malformed .html (out of memory)

Status: RESOLVED DUPLICATE of bug 379390

(Toolkit :: Safe Browsing, defect)

Description

[Luciano Aibar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Mozilla Firefox 2.0.0.6 on Windows XP SP2
Crash when opening:
http://lucianoaibar.no-ip.org/firefox.htm

Reproducible: Always

Steps to Reproduce:
1.Load Mozilla Firefox 2.0.0.6
2.type this URL: http://lucianoaibar.no-ip.org/firefox.htm
3.Program crash


Expected Results:  
Program freeze

I created this .htm file with some 0x01 bytes inside
"<a href='http://" + 0x01 + "www.example.com" + 65535 bytes of text + "'>link</a>

Comment 1

[Luciano Aibar]

Attachment: Malformed .html file that make Firefox crash

Comment 2

[Marco Perez [:mpk]]

WFM on recent Firefox/SeaMonkey trunk builds under
FreeBSD-current. The browsers correctly state:
"Server/Address not found"

Luciano, could you please try to reproduce the bug using
the latest Firefox trunk build from:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 3

[Luciano Aibar]

Now tested with:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.0a8pre.en-US.win32.installer.exe

and problem solved ;-)

Comment 4

[Jean-Michel Reghem]

confirmed on windows vista Business with branch 1.8.x

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7pre) Gecko/20070913 Firefox/2.0.0.4pre ID:2007091303

1) Going to http://lucianoaibar.no-ip.org/firefox.htm
2) click on the link
3) --> the firefox memory increase of 7Mo by second until the crash of firefox ... with 50% of cpu

If we wait a bit before killing the process, firefox shows the windows "Warning, unresponsive script" ... bug either continue, stop or debug script has an action ...

Comment 5

[Jean-Michel Reghem]

as this seems fix in trunk according to comment #3, maybe there is a dup somewhere fixing this on trunk ...
I'm looking

PS: the crash is due to out of memory, there is no talkback

Comment 6

[Daniel Veditz [:dveditz]]

This is due to the Phishing Protection code. If you turn off the "web forgery" detection option it doesn't happen, and when I break in the debugger it's stuck processing nsUrlClassifierTable.js ("line 1035" according to the script object, but that doesn't look right in the code).

It's simple resource exhaustion, which makes a nice denial-of-service but isn't an exploitable crash.

Comment 7

[Tony Chang (Google)]

It sounds like this is a dup of bug 379390.  That is, I don't think the 0x01 bytes matter, it's just a long URL and normalizing it JS takes a very long time.