363591 - Two ways to bypass Add-ons whitelist check

Status: RESOLVED INVALID

(Firefox :: Security, defect)

Description

[Deb Richardson [:dria] (plz NEEDINFO)]

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.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

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

[Benjamin Smedberg]

#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.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

(see also bug 347759 which is tangentially related to the problem of using referring-site instead of hosting-site)

Comment 4

[Mike Connor [:mconnor]]

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.

Comment 5

[Daniel Veditz [:dveditz]]

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.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 7

[Mike Connor [:mconnor]]

If we can fix installs to work like popup events, then I'm happy, tbh.  It just is kinda hard on the technical side.