1065876 - Bypass XPI Installation Prompt "Firefox prevented this site..." for Installing Addons

Status: RESOLVED DUPLICATE of bug 1042699

(Toolkit :: Add-ons Manager, defect)

Description

[Matthew Bryant]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.103 Safari/537.36

Steps to reproduce:

The latest version of Mozilla Firefox (version 32) suffers from a vulnerability that allows a remote attacker to bypass the warning prompt for installing addons. This can lead to arbitrary addon installation with only minor user interaction.

Image of prompt being bypassed:
http://i.imgur.com/FMCaSaz.png

To reproduce the exploit, perform the following steps:
1.	Obtain a regular Firefox addon
2.	Base64 encode the addon XPI file
3.	Create a data: URI with the base64 data (data:application/x-xpinstall;base64,XXX)
4.	Place this data: URI into a JavaScript URI like the following:
javascript:"<script>document.location= 'XXXXXXXX';</script>"
5.	Now, place this newly built URL into yet another data: URI (data:text/html;charset=utf-8,XXXX)
6.	This entire payload will now work inside the HTTP "Location" header and can be used to bypass the addon installation warning

The exploit abuses the weird fact that if no domain/origin is present when presenting an addon, Firefox for Windows will not display the warning prompt. I'm not sure why this happens, in Firefox for OS X/Linux you just get an addon warning with a blank domain name in the warning prompt. For some reason in Windows, the warning is just bypassed.

Here is the proof of concept (attempts to install a harmless addon):
http://itsclassified.info/addonpwn/ 

Proof of concept video:
http://www.itsclassified.info/addonpwn/addonpromptbypass.mp4

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. 




Expected results:

The warning prompt should be displayed.

Comment 1

[Matthew Bryant]

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.

Comment 2

[Benjamin Smedberg]

dveditz is this yours as owner of xpinstall? ;-) hot-potato!

Comment 4

[Matthew Bryant]

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

Comment 5

[Daniel Veditz [:dveditz]]

> 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)

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Matthew Bryant]

(In reply to Daniel Veditz [:dveditz] from comment #6)

After reading that thread I agree, since we now have installation-less plugins this is larger security risk. That being said, could the window not just close itself to hide the "Installation Complete" dialogue from the user upon installation (perhaps when it regained focus after the addon prompt)? This would prevent the user from noticing that an addon has just been installed. 

Just going off of comment #55:
"Because of the whitelist there should be no automatic triggering of the install dialog (except by previous consent by the user)."
This is subverted by use of the data:/javascript: URI trickery, so this protection is effectively bypassed. Perhaps having the "doorhanger" prompt displayed regardless of the host value being present would mitigate this problem? Would this create to much of a usability issue? I'm not seeing the downside.

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Minused for bounty as a low rated security issue.

Comment 10

[Kamil Jozwiak [:kjozwiak]]

(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!

Comment 11

[Matthew Bryant]

(In reply to Daniel Veditz [:dveditz] from comment #8)

Will do, is there any more information needed on my end for this bug?

Comment 12

[Matthew Bryant]

This appears to be fixed in the latest? Can anyone confirm?

Comment 13

[Daniel Veditz [:dveditz]]

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

Comment 14

[Matthew Bryant]

Any update on this?

Comment 15

[Daniel Veditz [:dveditz]]

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)

Comment 17

[Matthew Bryant]

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