bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Two ways to bypass Add-ons whitelist check




11 years ago
11 years ago


(Reporter: dria, Unassigned)


Firefox Tracking Flags

(Not tracked)


I accidentally discovered two ways to bypass the Add-ons whitelist check this morning.

1) I was reading Myk's post (http://www.melez.com/mykzilla/2006/12/persistent-site-specific-prefs.html) in Vienna, an RSS Feed Reader for Mac.  I clicked the "Install Content Preferences" link in the Feed reader, which brought Firefox to the front and gave me the Add-on installation dialog (with the countdown button, etc).  I do not have Myk's site in my Add-ons whitelist, so it bypassed the whitelist check.

2) I copied the URL to Myk's extension's xpi and pasted it into the Location bar.  Same result -- the Add-on installation dialog was presented with the countdown button, etc., again bypassing the whitelist.

Clicking on the link in the post displayed in Firefox (ie: regular browsing), the extension installation was blocked as expected.
I recommended to Deb that we mark this security sensitive since I wasn't sure, but we might end up opening it quickly.

And speaking of open, this also works on Linux and OSX:

open http://www.melez.com/mozilla/cpref.xpi

and on w32:

firefox.exe http://www.melez.com/mozilla/cpref.xpi

The question is whether or not this is a side-effect of allowing drag-n-drop install from the local filesystem, or just an oversight.

Comment 2

11 years ago
#2 is by design; if you paste a URL into the urlbar, we load it no matter what

#1 is a bit trickier: we're loading the URL from another application, so we don't have any referring site context.
(see also bug 347759 which is tangentially related to the problem of using referring-site instead of hosting-site)
IIRC, both of these are absolutely by design.  The whitelist was intended to prevent sites from bombarding users with unwanted install prompts (you can essentially force a user to either install or force-quit the app otherwise).  In cases where there is an explicit action, the dialog itself is sufficient.

Removing security flag, this is not an exploit at all.
Group: security
Both of these are by design: the user has made an explicit action to open an install package (or a program running on their machine has, and if it's malicious it could do worse). There's no need for an extra hurdle in addition to the install confirmation dialog.
Last Resolved: 11 years ago
Resolution: --- → INVALID
I believe the contentious experience here is:

 - I click a link in my web browser, I have to go through the whitelist
 - I click a link in email, RSS, IM, etc, I don't have to go through the whitelist

If the response is "the whitelist is purely to prevent drive-by attacks from inside the browser", my comeback will be "oh, ok, that's a crappy way to do that, and I'll file a follow-on bug to fix that in the future". :)

If the response is "the whitelist prevents drivebys and also represents the only list of websites from which we think you should, by default, trust remote software install," then we should be consistent for the case where the user has clicked on a link in some other application that results in the page being loaded in Firefox. To the user, that's the exact same thing as clicking a link in the browser.
If we can fix installs to work like popup events, then I'm happy, tbh.  It just is kinda hard on the technical side.
You need to log in before you can comment on or make changes to this bug.