In addition, when this is looped you can spam the user with addon installation prompts: http://itsclassified.info/loop.php This is pretty effective at freezing the user's browser (depending on how fast the computer is, etc), or just spamming a lot of installation prompts.
dveditz is this yours as owner of xpinstall? ;-) hot-potato!
Just tested and is working on OS X as well. The only thing it doesn't appear to work for is my version 28.0 on Ubuntu 13.10 (displays the prompt with nothing for the domain).
> Depending on the Windows version, the waiting prompt seems to vary. In > Windows XP the wait time is much less than in Windows 7 for example when > I've tested it. The delay time should be 1 second everywhere, but in older versions it was 2 seconds (see the security.dialog_enable_delay pref). The site whitelisting originally led to no prompt whatsoever if a non-whitelisted site tried to do an install. Mainly, though, it's an anti-annoyance check rather than a security dialog. Quite a while ago the Firefox front-end team decided that rather than prevent non-whitelisted sites from triggering installs entirely it would show that little doorhanger thing (in the past an infobar). Hostless pages are allowed to bypass that prompt so that people can install from the local disk, but given the proliferation of hostless schemes maybe we should change that to an explicit check for file: schemes. The most disturbing part of your movie for me is that holding Enter works. That dialog--all security dialogs--should have the safe option (usually Cancel) as the default choice. That's not a complete protection because there are often hot keys that would work in the same type of attack ("hold down 'y' for yes"), but those keys would be unusually specific and might alarm potential victims more than the enter key does. I fixed a version of this a decade ago (bug 149478) but the front-end code has been rewritten since then. Matt, Kamil: as you test various things in the product keep an eye out for security prompts where the potentially unsafe action is the default selected button (such that Enter alone activates it)
Focusing the cancel button was WONTFIX in bug 240637 so I guess the best we can do is make sure the Install button is not focused. Of course part of the rationale was "Accepting the install is not that destructive as you can cancel the install before you restart" (bug 240637 comment 55) and in the age of restartless add-ons this is no longer true -- once you click that install button you are pwned.
Right, we're dealing with two strata of implementations here with conflicting goals/values. When I first created this feature if you weren't on the whitelist then nothing happened, full-stop. Because we wanted people (especially developers) to be able to install from local disk we needed to add the whitelist bypass for hostless installs (which in hindsight could have been file: specific instead of trying to be general; maybe there was another case I'm not remembering). Later on there was the desire to let any site ask for an exception, because apparently for non-evil sites it was too hard for them to ask users to download the .xpi and then ask the user to click on it to install as they would with any setup.exe they got from some possibly dodgy site. Not a fan of that train of thought because 1) the damage caused by malware far outweighs mere convenience (and I see a LOT of malware), and 2) hardly anyone has the ability to distinguish dodgy from legit sites, especially given the ability for ads to inject evil into otherwise nice sites. I wanted users to treat it like a executable install because that's the power add-ons have and a friendly "add-on" dialog misleads people into thinking it's a relatively safe action. Others thought that would just train people to think that downloading and launching setup.exe was as safe as reviewed add-ons on AMO. In any case, when the more generic way to bypass the whitelist was invented the original hardcoded "no host" bypass should have been folded into it.
Minused for bounty as a low rated security issue.
(In reply to Daniel Veditz [:dveditz] from comment #5) > Matt, Kamil: as you test various things in the product keep an eye out for > security prompts where the potentially unsafe action is the default selected > button (such that Enter alone activates it) Will do, thanks for the heads up Dan!
(In reply to Daniel Veditz [:dveditz] from comment #8) Will do, is there any more information needed on my end for this bug?
This appears to be fixed in the latest? Can anyone confirm?
(In reply to Matthew Bryant from comment #12) > This appears to be fixed in the latest? Can anyone confirm? It's not fixed in Nightly, anyway. I would be surprised if something changed it in in 37 but I'll check it out.
Any update on this?
The testcase at http://itsclassified.info/addonpwn/bypass.php redirects to a data: URL (captured at the end of this comment) which then sets document.location to a .xpi URL. In this example the .xpi is also a data: URL but I don't think that's necessary. This trick is the main idea of bug 1042699 so I think it's a dupe. The XPInstall UI changed in Firefox 40 and no longer shows the source origin for the install package. Normally it at least shows the site requesting the install, but in the case of the hostless data: URL it simply says "this site". This means any reputable site that has an XSS bug can be used to fool users into installing unknown code. It also means a 3rd-party iframe (malvertising) could do the same and the user would assume it was the top-level site doing the install. Firefox 40 does introduce signature checking and /warns/ on unsigned content. Hopefully people would stay away but one of the reasons it only warns rather than blocks is because we're in a transition period -- users may see lots of unsigned-addon warnings in the next release cycle or two until blocking is turned on. Once signing is fully rolled out that doesn't fully solve the problem because nothing stops someone from pointing at old signed content that contains a security flaw. We can't blocklist every old version of every add-on and such flaws might only be known to the attacker. The new UI does not have a default button nor keys to trigger the buttons (at least on Mac; will have to test on Windows and see), and it takes 3 or 4 tabs to get to the Install button before a space/enter will activate it. It should require the social engineering to convince someone the install is necessary and safe, you won't be able to get the user playing a button-mashing game and then pop this up in front of them. Upgrading the severity to reflect product changes, but then I'll be making this a dupe. data:text/html;charset=utf-8,<script>document.location = 'data:application/x-xpinstall;base64,UEsDBAoAAAAAALVmV.....'</script> (truncated because bugzilla has a comment-length cap, but you get the idea)
@dveditz can we make this public? Since #1042699 is public there shouldn't be any reason why this one can't be public as well.