289761 - extension update ignores Allowed Sites list

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[dmeybohmlkml]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Unlike extension install, extension update doesn't check the allowed sites list
before downloading and installing an update to an installed extension.  An
extension author could use this to get control of other browsers that have
installed his extensions.  While an extension author already has this ability,
that ability is held in check by the Allowed Sites list and the potential
scrutiny of extensions on sites like addons.mozilla.org -- since an extension is
static once uploaded there, it could eventually be identified as malicious and
taken down.  However, the attacker's website can avoid this scrutiny -- it can
masquerade most of the time as seemingly benign, while selectively uploading a
malicious extension to some users.  This can be done while maintaining that
extension's good reputation on addons.mozilla.org by keeping a good extension
uploaded there that points to the attacker's website in the updateURL.

I noticed this was possible after downloading the WebmailCompose extension. On
http://addons.mozilla.org/ the extension version is now (Apr 9 2005) 0.5.7. The
 updateURL in the extension is
http://jedbrown.net/dev/Mozilla/webmailcompose.rdf , and the version there is
0.6.0.  So, if you download that extension from addons.mozilla.org and then try
to update it, the extension will be updated from a website that is not on the
Allowed Sites list.

Reproducible: Always

Steps to Reproduce:
1. Install WebmailCompose 0.5.7 from addons.mozilla.org
2. Restart Firefox
3. Update the extension to 0.6.0 from jedbrown.net with Tools -> Extensions ->
Update
Actual Results:  
The extension updated itself from jedbrown.net, a site not in the Allowed Sites
list, which contained only update.mozilla.org and addons.mozilla.org.

Expected Results:  
The extension should only be updated from websites the user trusts for
installing extensions.

One possible solution:
The installation URL where the original .xpi was downloaded could be recorded
and mangled to a .rdf file according to some standard heuristics before updating
an extension.  For example, if extension WebmailCompose is downloaded from
https://addons.mozilla.org/webmailcompose/webmailcompose-0.5.7.xpi, the URL
https://addons.mozilla.org/webmailcompose/webmailcompose.rdf can be checked for
updates to the extension.  The .rdf and .xpi update URLs should then be checked
against the Allowed Sites list before installing the new extension.  The
updateURL of extensions should be ignored.

Comment 1

[Jesse Ruderman]

I vote for wontfix.

Comment 2

[Daniel Veditz [:dveditz]]

I understand the concern and we plan to change the policy for extensions hosted
by mozilla.org that will require updates come from mozilla.org as well. But in
general this is a wontfix -- once you've installed a malicious extension it
could do its damage directly or silently update itself using low-level calls. 

The "allowed sites" list for installs is simply to prevent sites from annoying
users with modal dialogs until they give in and install. The update mechanism is
opt-in: the user has to click on the update icon or a dialog button to get it.
The update dialog that comes up does show the user where each update will come
from and gives the user a chance to reject it at that time.

Comment 3

[dmeybohmlkml]

(In reply to comment #2)
> I understand the concern and we plan to change the policy for extensions hosted
> by mozilla.org that will require updates come from mozilla.org as well. But in
> general this is a wontfix -- once you've installed a malicious extension it
> could do its damage directly or silently update itself using low-level calls. 

Sure, but that isn't disputed -- the main thrust is that it is more difficult to
learn whether an extension is trustworthy when extensions can be uploaded from
URLs chosen by extension authors.

> The "allowed sites" list for installs is simply to prevent sites from annoying
> users with modal dialogs until they give in and install. The update mechanism is
> opt-in: the user has to click on the update icon or a dialog button to get it.
> The update dialog that comes up does show the user where each update will come
> from and gives the user a chance to reject it at that time.

Yes, manual update makes it less exploitable. Good point.