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.
I vote for wontfix.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
(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.
You need to log in before you can comment on or make changes to this bug.