Closed Bug 379390 Opened 16 years ago Closed 7 years ago

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


(Toolkit :: Safe Browsing, defect)

2.0 Branch
Not set





(Reporter: dveditz, Unassigned)




(Keywords: hang)


(1 file)

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

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.

Turning off the phishing protection option in prefs makes the problem go away.
If there's an easy fix and we need a re-spin for some reason it would be worth getting this one into 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.
It's likely that the patch on bug 368998 fixes this performance issue.
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]
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.
bug is fixed in firefox ?
not fixed.

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?
Flags: blocking-firefox3? → blocking-firefox3+
Severity: normal → critical
Keywords: hang
Target Milestone: --- → Firefox 3 M9
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Priority: -- → P3
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Is this really still unfixed? 
The latest Linux nightly doesn't crash, but it does take a long time and chew up CPU.
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 → ---
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.
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.