Closed Bug 415500 Opened 16 years ago Closed 16 years ago

bad userpass URL parsing leads to HelperApp dialog spoofing

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dveditz, Assigned: dveditz)

References

Details

(Keywords: verified1.8.1.13, Whiteboard: [sg:dupe 415034]) 

Similar to bug 415496 the same problem appears in the HelperAppDialog

http://:xxxxxxxxxxxx@releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0/update/win32/de/firefox-2.0.complete.mar

Should say that the host is http://releases.mozilla.org, but due to bug 415034 says "http://la.org"

Unlike some of the other variants I can't seem to chop off more than the host and work down the path. That limits the spoofing quite a bit unlike some of the other cases where the attacker can completely hide their domain by putting an arbitrary display domain in the path.

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in&rev=1.59&mark=545#538
Assignee: nobody → dveditz
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.13+
Flags: blocking-firefox3?
Whiteboard: [sg:dupe 415034]
Flags: blocking-firefox3? → blocking-firefox3+
bug 415034 fixed on trunk
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Fix checked into 1.8 branch
Keywords: fixed1.8.1.13
FF2.0.0.12 going to http://:xxxxxxxxxxxx@releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0/update/win32/de/firefox-2.0.complete.mar prompts you to download the .mar file. In 2.0.0.13, it doesn't try to download the file (instead it tries to do a google search for the whole thing).

Is this correct behavior with the fix? The bug lacks a little detail.
Verified after talking to Dveditz in IRC using http://@releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0/update/win32/de/firefox-2.0.complete.mar as the url. This was with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13.
Keywords: fixed1.8.1.13 → verified1.8.1.13
I had a reply but my browser hung -- should never try to multitask :-(

There were two possible fixes in bug 415034, one preserved ":pass" as a working userinfo form and one made it invalid. Keeping it working resulted in a potential phishing danger so we blocked those. That turns my testcase into an invalid URI (proving the underlying fix is in your build) which then bubbles into the "if it's not a hostname try a search" mechanism.

If you use a completely empty user:info section you can still test this bug, but the broken state is a little harder to see since only one character was eaten. (e.g. http://@releases.mozilla.org/...)
Flags: blocking1.8.0.15+
Group: security
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.