User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:188.8.131.52) Gecko/20070725 Firefox/184.108.40.206
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:220.127.116.11) Gecko/20070725 Firefox/18.104.22.168
Mozilla Firefox 22.214.171.124 on Windows XP SP2
Crash when opening:
Steps to Reproduce:
1.Load Mozilla Firefox 126.96.36.199
2.type this URL: http://lucianoaibar.no-ip.org/firefox.htm
I created this .htm file with some 0x01 bytes inside
"<a href='http://" + 0x01 + "www.example.com" + 65535 bytes of text + "'>link</a>
Created attachment 281331 [details]
Malformed .html file that make Firefox crash
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:
Now tested with:
and problem solved ;-)
confirmed on windows vista Business with branch 1.8.x
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52pre) Gecko/20070913 Firefox/184.108.40.206pre 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 ...
as this seems fix in trunk according to comment #3, maybe there is a dup somewhere fixing this on trunk ...
PS: the crash is due to out of memory, there is no talkback
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.
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.
*** This bug has been marked as a duplicate of bug 379390 ***