User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061024 BonEcho/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061024 BonEcho/2.0 Go to some url, for example http://www.google.ca (but most any one will work fine for this bug). Enter, in the location bar a javascript: javascript:void(InstallTrigger.installChrome(InstallTrigger.SKIN,'http://kmgerich.com/downloads/pinstripe_firefox.jar','Pinstripe v4.9')) The browser will give a warning: <<Firefox prevented this site (www.google.ca) from asking you to install software on your computer.>> And offer you an opportunity to allow the site to install software. But the message is not as clear as it should be. A) Google isn't installing the software. The url was chosen arbitrarily. There's nothing Google could do about that! B) The software that is going to be installed is from http://kmgerich.com/downloads/pinstripe_firefox.jar. But that is not mentioned anywhere in the warning. C) If you allow "google" to install software, firefox does then pop up a different software installation dialog box asking you if you want to install the skin. This dialog box does show the url from which the skin is being downloaded. But there is no necessity or opportunity to block or allow the site from which the skin is actually being downloaded. This site doesn't have to be on the list of sites allowed to install software for this site to actually install software! I think this is an omission. Reproducible: Always Steps to Reproduce: 1.Go to some arbitrary url. 2.Enter a javascript uri which leads to a particular location to install software Actual Results: Mozilla claims the arbitrary url is installing the software, when it isn't. The site actually installing the software doesn't need to be on the list of sites allowed to install software. Expected Results: Mozilla shouldn't assume that inputted javascript uris have anything to do with the prior uri in the location bar. It should be more clear where the software is being installed from. Also, the site from which the software is actually being downloaded from should be in the 'list of sites allowed to install software', and there should be a user interface to add that site to the list of sites allowed to install software. There is the possibility that some users might be susceptible to a request in an email or webpage that tells to user to copy a certain javascript uri, go to some website that the user might trust, paste the uri into the location bar, note that firefox is "telling" the user that the software is being installed by the trusted website, so that the user has nothing to worry about, and finally to click 'ok' install the software.

If you use a bookmarklet (e.g. by entering a javascript: URL into the address bar), it is treated exactly as if it were part of the page. This can't realistically be changed just for XPIs; if we tried, a malicious javascript: URL could just add text/links to the "trusted" page offering to install something. So there are two separate things wrong here: (1) Users can enter javascript: URLs into the address bar, causing scripts to run against the current page. Because this is very different from what entering an http: URL into the address bar does, a reasonable user might not think it is dangerous. This problem is covered by bug 305692. (2) The fact that Firefox says *Google* is trying to install the software -- and says so "within" Google's content area -- is misleading I think it dangerous. Here's an alternate exploit that doesn't involve JavaScript at all: First, I use my SEO skills to make a bunch of pages I control, whose titles are all "Install Google PornAllower to un-hide this search result", appear high in search results for certain porn-related searches. Then, I make it so that when users click on one of those search results, instead of getting a web page (like Google's crawler gets), they get an XPI. Firefox will tell them that Google is trying to install some software, and the title of the search result will lead them to believe that Google is in fact suggesting that they install some software. Note that while the initial information bar says that Google is trying to install the software, and it is Google that must be added to the whitelist, the actual installation dialog only the URL of the actual XPI. But a user who is actually at Google and just saw that Google is "trying to install software" is likely to overlook the URL string in the installation dialog. But URLs are a bit opaque to humans, and http://www.google-pornallower.com/ might look fine to someone who just saw http://www.google.com/ "attempt to install" an extension. There are a bunch of WONTFIXed bugs about this referring-site-vs-hosting-site issue for XPIs: bug 343955, bug 257055, bug 265351. Here's a radical proposal: don't let extensions be hosted off-site. Clarifications: * "Off-site" might be an effective-TLD-plus-one test, so that addons.mozilla.org can continue hosting extensions on a separate server from the one that displays information about them. * At first I was tempted to say there should be an automatic replacement page for the XPI, saying "this site is offering an extension for you to install; click here to install it". But I think this is a bad idea, because it would make "Please go install this old, vulnerable version of Greasemonkey" attacks even easier than they are now. Better to block it entirely. crf, do you agree? Is it ok with you if I change this bug to cover only (2), since (1) is covered by bug 305692?

Yes, change the bug to cover your second point. What you've written makes sense to me. Especially https://bugzilla.mozilla.org/show_bug.cgi?id=305692#c3 . If that were implemented, then it would resolve the particular case I encountered. I agree also with the suggestion that sites linking to an installable extension be on the same domain. That would certainly be a good practice to follow, but it clearly isn't always followed now, and it is hard to know if there are legitimate cases where it couldn't be followed. --- Some of the comments in the bugs that were linked to in comment #1 show a conflict between what users (see bug 257055 comment4) would consider to be security features, but which are in fact only, apparently, anti-annoyance features (bug 343955 comment3).

We could make a distinction in the blocking events to distinguish a document load (sent from the application/x-xpinstall content handler) from a scripted InstallTrigger. If someone's got script on their page, or fails to sanitize javascript: links then I think it's perfectly fair to say they are the ones doing it. But if you can come up with a better wording that still conveys the information about which page is the source (important information when there's potential frames hosted on different sites) that's fine too. Don't get me started about the placement of the infobar within the content area... It's perfectly valid for one site to offer links to installs on another site in many different cases. There are two sites to trust in that case, the recommending site and the source site (or signer in the unfortunately rare case the zippy is signed).

The EM code isn't involved in this whatsoever.

addons.mozilla.org is now going through contortions (bug 523249) to prevent user-supplied links from being subject to addons.mozilla.org's whitelist entry. I don't think we can expect the same of every site that hosts a Firefox extension.

Maybe this is a naive idea, but just throwing it in there: couldn't we check (the second level part of?) the domain on which the add-on install is linked versus (the same part of) the location of the actual XPI, and present both to the user (with appropriate wording) if they are different? We might even do that if the linking page is whitelisted and the location of the XPI isn't, IMHO. AMO could just whitelist the actual location of the XPIs, although I think they're all on *.mozilla.org, so depending on how this is implemented it might not be necessary.