User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:126.96.36.199) Gecko/20070725 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:184.108.40.206) Gecko/20070725 Firefox/220.127.116.11 Mozilla Firefox 18.104.22.168 on Windows XP SP2 Crash when opening: http://lucianoaibar.no-ip.org/firefox.htm Reproducible: Always Steps to Reproduce: 1.Load Mozilla Firefox 22.214.171.124 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>
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/
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 ;-)
confirmed on windows vista Business with branch 1.8.x Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199pre) Gecko/20070913 Firefox/188.8.131.52pre 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 ... I'm looking 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.