Note: There are a few cases of duplicates in user autocompletion which are being worked on.

A very long URI ('aaa...') hangs under phishing protection code (CVE-2007-2671)

RESOLVED INVALID

Status

()

Toolkit
Safe Browsing
--
critical
RESOLVED INVALID
10 years ago
a year ago

People

(Reporter: dveditz, Unassigned)

Tracking

({hang})

2.0 Branch
Points:
---
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
wanted1.8.1.x +
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

Similar to bug 370860 but still happening even after that one has been fixed in 1.8.1.4

bug 370860 dealt with a lot of slashes ('////////....') and the URL in question here is a lot of text ('aaaaaa....').

Reported as a crash on Full-Disclosure, but I and several F-D readers only see a CPU spike.
http://archives.neohapsis.com/archives/fulldisclosure/2007-05/0005.html

Turning off the phishing protection option in prefs makes the problem go away.
Created attachment 263384 [details]
testcase from full-disclosure post
Testcase originally from
  http://www.critical.lt/research/opera_die_happy.html 

Had to zip the testcase for size, access it using Mozilla browsers as
  jar:https://bugzilla.mozilla.org/attachment.cgi?id=263384!/opera_die_happy.html
If there's an easy fix and we need a re-spin for some reason it would be worth getting this one into 1.8.1.4. But since there's an easy workaround (turn off phishing protection) and it's just a resource hog and the similar bug 370860 required re-writing JS bits as C++ I don't think this is a true blocker.
Assignee: nobody → tony
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
I'm indeed seeing a crash, when I'm closing the tab with the long url, I was using a Bon Echo build of 2007-04-27.
I'm getting useless talkback ID's, though:
Talkback ID: TB31715490M
msvcrt.dll + 0x378c0 (0x77c178c0)
I did manage to crash once (TB31715128), which looks like bug 282660.

Comment 6

10 years ago
It's likely that the patch on bug 368998 fixes this performance issue.

Comment 7

10 years ago
On my trunk build, the above jar URL takes about ~5-6 seconds.  But you can always make a longer URL and the time is still going to be linear w.r.t. URL length.
From TB31715128:

Stack Signature	 jsds_NotifyPendingDeadScripts 6d364232
Product ID	Firefox2
Build ID	2007043003
Trigger Time	2007-05-01 13:33:29.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	jsd3250.dll + (00004caf)
URL visited	
User Comments	
Since Last Crash	104638 sec
Total Uptime	104638 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/jsd/jsd_xpc.cpp, line 501
Stack Trace 	
jsds_NotifyPendingDeadScripts  [mozilla/js/jsd/jsd_xpc.cpp, line 501]
jsds_GCCallbackProc  [mozilla/js/jsd/jsd_xpc.cpp, line 519]
js_NewGCThing  [mozilla/js/src/jsgc.c, line 1420]
js_NewString  [mozilla/js/src/jsstr.c, line 2442]
js_NewStringCopyZ  [mozilla/js/src/jsstr.c, line 2576]
JS_NewUCStringCopyZ  [mozilla/js/src/jsapi.c, line 4497]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1300]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsContentTreeOwner::SetStatus  [mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 431]
nsWebShell::OnOverLink  [mozilla/docshell/base/nsWebShell.cpp, line 587]
nsGenericElement::TriggerLink  [mozilla/content/base/src/nsGenericElement.cpp, line 3754]
nsGenericHTMLElement::HandleDOMEventForAnchors  [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 1737]
nsHTMLAnchorElement::HandleDOMEvent  [mozilla/content/html/content/src/nsHTMLAnchorElement.cpp, line 295]
nsEventStateManager::SendFocusBlur  [mozilla/content/events/src/nsEventStateManager.cpp, line 4452]
nsEventStateManager::SetContentState  [mozilla/content/events/src/nsEventStateManager.cpp, line 4089]
nsGlobalWindow::RestoreWindowState  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 7454]
nsDocShell::RestoreFromHistory  [mozilla/docshell/base/nsDocShell.cpp, line 5536]
HandleRestorePresentationEvent  [mozilla/docshell/base/nsDocShell.cpp, line 5115]
shdocvw.dll + 0x150c24 (0x778b0c24)
nsSimplePageSequenceFrame::Reflow  [mozilla/layout/generic/nsSimplePageSequence.cpp, line 240]
0x83575653
Duplicate of this bug: 382295

Comment 10

10 years ago
that stack would be bug 282660. If it's reproducable, it'd be greatly appreciated if you added some logging and figured out what it means for the script to be null.

Comment 11

10 years ago
bug is fixed in firefox 2.0.0.4 ?

Comment 12

10 years ago
not fixed.

Changelog++
Depends on: 368998
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13+
Flags: blocking-firefox3?

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Severity: normal → critical
Keywords: hang
Target Milestone: --- → Firefox 3 M9

Updated

10 years ago
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Duplicate of this bug: 396572

Updated

10 years ago
Priority: -- → P3
Target Milestone: Firefox 3 M10 → Firefox 3 M11

Comment 14

10 years ago
Is this really still unfixed? 

Comment 15

10 years ago
The latest Linux nightly doesn't crash, but it does take a long time and chew up CPU.
Duplicate of this bug: 417233

Updated

10 years ago
Priority: P3 → P4
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Summary: A very long URI ('aaa...') hangs under phishing protection code → A very long URI ('aaa...') hangs under phishing protection code (CVE-2007-2671)
Assignee: tony → nobody
Priority: P4 → --
Target Milestone: Firefox 3 beta3 → ---
(Assignee)

Updated

3 years ago
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
The original test case now returns a 403.

When trying to open the jar URL from comment 2, I get:

"Unsafe File Type

The page you are trying to view cannot be shown because it is contained in a file type that may not be safe to open. Please contact the website owners to inform them of this problem.

Please contact the website owners to inform them of this problem."

Since it cannot be reproduced anymore, I'll close this bug.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.