1539591 - Remove special navigator.mozAddonManager API from addons.mozilla.org

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Alex Gaynor [:Alex_Gaynor]]

This was a factor in the bug 1538007 sandbox escape.

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

It sounds from https://bugzilla.mozilla.org/show_bug.cgi?id=1539590#c9 that this depends on bug 1540173 but that isn't totally clear to me.

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

So I've been working on Bug 1539595 to isolate addons.mozilla.org which I think would lessen the need for this (although XSS on AMO would still be a concern.) After creating a new remote type for AMO, I was going to drop a check for the remotetype right here: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/toolkit/mozapps/extensions/addonManager.js#195

But during my testing I found that if another site (like example.com) serves you an XPI; we go through this same code path to (prompt to) install it.

As long as we support side-loading extensions in that way; is there a meaningful distiction between addons.mozilla.org where we benefit from isolating it? Are their privileged API calls that only AMO make that I can put remoteType checks into to secure?

Comment 3

[Robert Helmer [:rhelmer]]

I haven't been working on add-ons manager the last few years, aswan would be more qualified to answer.

Comment 4

[Andrew Swan [:aswan]]

The code linked in comment 2 is used in two cases:

1. When a web page uses the InstallTrigger API
2. When a web page links directly to an xpi file

I understood this bug to be about a third case, which is the mozAddonManager api, this is only exposed to AMO. The API exposed to AMO is defined by:
https://searchfox.org/mozilla-central/source/dom/webidl/AddonManager.webidl

When that API is invoked from content, the message to the parent process isn't very clearly named, but it is this one:
https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/toolkit/mozapps/extensions/addonManager.js#219

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

After Reading Comments 1-5 on Bug 1539598 it seems like we cannot remove the mozAddonManager (without completely re-architecting AMO and building something that functions similar to mozAddonManager). Bug 1539595 isolates AMO so the mozAddonManager functionality is only available from the special remote type which is a mitigation we can effectively deploy today.

I believe that this is a WONTFIX.

Andrew, William, could one of you confirm my understanding?

Comment 6

[William Durand [:willdurand]]

(In reply to Tom Ritter [:tjr] from comment #5)

After Reading Comments 1-5 on Bug 1539598 it seems like we cannot remove the mozAddonManager (without completely re-architecting AMO and building something that functions similar to mozAddonManager). Bug 1539595 isolates AMO so the mozAddonManager functionality is only available from the special remote type which is a mitigation we can effectively deploy today.

I believe that this is a WONTFIX.

Andrew, William, could one of you confirm my understanding?

I don't have access to Bug 1539595 but I believe this is indeed a wontfix, for now at least, since AMO still uses mozAddonManager. There are plans to change the way add-ons are installed in AMO but this is still under discussion.