Closed Bug 1406795 Opened 2 years ago Closed 2 years ago

block_mozAddonManager pref enables extensions to run and take over AMO, install wrong extension

Categories

(Toolkit :: Add-ons Manager, defect)

57 Branch
defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- unaffected
firefox57 --- affected
firefox58 --- affected

People

(Reporter: Tomislav, Unassigned)

References

Details

Bug 1384330 added the pref to not expose mozAddonManager to AMO.

Unfortunately, the same `IsValidHost` method is used to control extensions access to AMO, and could allow extensions to trick users into installing wrong/evil extensions.
The mozAddonManager restriction was originally created when we had legacy extensions that:
1. did not have install-time notifications and
2. could silently do all sorts of nasty things

As of firefox 57, things have changed quite a bit, I think we should just consider relaxing (or rather removing altogether) the restrictions on webextensions interacting with sites that have access to mozAddonManager.
IsValidHost will always return false if that's set, which means mozAddonManager won't work. How does that lead to people installing wrong or evil extensions?
(In reply to Andy McKay [:andym] from comment #2)
> IsValidHost will always return false if that's set, which means
> mozAddonManager won't work. How does that lead to people installing wrong or
> evil extensions?

AMO has the ability to use InstallTrigger without that "Firefox prevented this site from installing software" notification so if a user has used the pref to disable mozAddonManager, then they suddenly get to inject content scripts and can use InstallTrigger.  But post-57 all they can do is install a webextension which comes with its own install confirmation prompt.
Sorry, zombie I'm missing something here, could you elaborate.
Flags: needinfo?(tomica)
If we consider "Convincing the user to change the pref" as a threat we guard against, this is as serious as protecting AMO because of access to mozAddonManager: 

 * Using content scripts and/or webRequest (StreamFilter), an extension can install a Service Worker on AMO while this pref is flipped, and then convince the user to flip it back off, and have access to mozAddonManager.

(note however that I'm not as familiar with install flows and security implications, and if we, as Andrew suggests want to abandon guarding access to mozAddonManager and AMO pages, then this is similarly a non-issue)
Flags: needinfo?(tomica)
And even disregarding mozAddonManager, AMO has some permissions and UX implications for users:

 * A link on AdBlock Plus page (with stars and millions of users) could be changed to actually install unlisted/unreviewed "AdBlck Plus" extension from Evil"R"Us.

(again, not an expert at this, not claiming this is a real threat if more knowledgeable people disagree)
(In reply to Tomislav Jovanovic :zombie from comment #6)
> And even disregarding mozAddonManager, AMO has some permissions and UX
> implications for users:
> 
>  * A link on AdBlock Plus page (with stars and millions of users) could be
> changed to actually install unlisted/unreviewed "AdBlck Plus" extension from
> Evil"R"Us.
> 
> (again, not an expert at this, not claiming this is a real threat if more
> knowledgeable people disagree)

A malicious extension with the rights to inject content scripts can do all sorts of nasty phishing things, I don't think there's anything particularly special about AMO here.  To be clear, that's not to say this isn't a problem, its that this specific threat is bigger and more general than anything about AMO.
Can't mozAddonManager probe for information about installed extensions as well? That's not a security issue but is exactly the kind of privacy issue the resistFingerprinting pref tries to kill off.

Does this bug need to be a hidden security bug? Not an issue in stock Firefox and presumably will be fixed before the Tor browser moves to ESR59.
Flags: needinfo?(tomica)
The pref is also present in firefox, though off by default.  I'm not really familiar our policies to decide if this should be hidden or not.

Kris, care to chime in on this or any other questions raised above?
Flags: needinfo?(tomica) → needinfo?(kmaglione+bmo)
(In reply to Daniel Veditz [:dveditz] from comment #8)
> Can't mozAddonManager probe for information about installed extensions as
> well? That's not a security issue but is exactly the kind of privacy issue
> the resistFingerprinting pref tries to kill off.

Yes. It's not as powerful as it used to be, but it still represents a privilege escalation, since extensions don't usually have access to that information without requesting special privileges.

> Does this bug need to be a hidden security bug? Not an issue in stock
> Firefox and presumably will be fixed before the Tor browser moves to ESR59.

I don't think so.

(In reply to Tomislav Jovanovic :zombie from comment #9)
> Kris, care to chime in on this or any other questions raised above?

I'm not especially concerned about this. There are fairly limited ways to exploit this compared to the mozAddonManager API at the time I originally added this restriction.

It's true that extensions could conceivably try to modify AMO in ways that might trick users who don't read the install prompts carefully, but there's only so far that gets you.

It definitely allows them to bypass the second install prompt that InstallTrigger usually shows, but I'm not convinced that those are especially effective to begin with.
Flags: needinfo?(kmaglione+bmo)
Thanks for bringing this up zombie, but I'm not worried about this. At this point I'd recommend we resolve as "won't fix" or "works for me" this and open the bug up.
Group: toolkit-core-security
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Stopped working for me in v60.0b3, extensions no longer work on mozilla addons site.
You need to log in before you can comment on or make changes to this bug.