1554596 - Investigate assertion that ensures AMO and accounts.firefox.com get site-isolation

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P2)

Description

[Frederik Braun [:freddy]]

It was suggested to me to investigate, whether we want assertions elsewhere in the code, that ensure we don't load the above mentioned services in a non-isolated way.

Comment 1

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

That's a good idea, and probably a general case of the type of investigation I did to find 1538072.

That said, even if its loaded somewhere else, we SHOULD make sure that ONLY the privileged process created by receives the blessing for privileged content. Or to say that another way: the implementation of mozAddonManager MUST check to ensure that the child process it is talking to is the privileged content process (the new one tom has added for amo and FxA).

Comment 2

[Tom Ritter [:tjr]]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1539595#c11 which talks about how accounts.firefox.com is not always the right domain to care about.

Comment 3

[Andrew Overholt [:overholt]]

Are you still working on this, Freddy? Is it possible for you to assign a priority?

Comment 4

[Frederik Braun [:freddy]]

Here's my (long) summary:

Setup:
Use new browser profile with chrome debugging enabled.
Identifying which tab is in which process is done with about:memory. The string to search for is (window-bojects/top(

Manual testing with web capabilities

One can loading addons.mozilla.org and accounts.firefox.com manually. They are always in their own Web Content process. If there a process that contains already one of them, it will be reused. Navigations, popups, etc. from other content processes all land in this new process. Navigating the opener of a popup to any of the protected domains severes the handle (opener becomes null), just like with a normal popup.
<iframe> doesn't work, due to the X-Frame-Options header.

There is a "Privileged Content" process, which contains about:newtab. However, AMO and FxA get their own Web Content process. Different process type means different enforcement? Is this a bug?

Attempts besides navigations/popups etc:

Starting off with an unprivileged content process (e.g. example.com) and mucking around using chrome privileges with the Browser Content Toolbox[1]. This simulates a compromised web content process within the sandbox.

Starting with code snippets like

var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
var we = Services.ww.getWindowEnumerator();
win1 = we.getNext()

we can get window handles and start opening/loading stuff into the existing window.

Setting the location of the object or calling into window-open APIs, have so far lead
to assertion failures (https://crash-stats.mozilla.org/report/index/625cf772-431f-45b2-9dba-53b9c0200122) or exceptions that disconnect the debugger from the content process.

Another remaining avenue is finding an IPC call that loads and renders remote data and sends it to the child process, but this would only give us data which likely isn't associated to the logged in Firefox Account? I tried messing with things like view-source and various about: pages, but no luck.

[1] https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Comment 5

[Frederik Braun [:freddy]]

(In reply to Frederik Braun [:freddy] from comment #4)

There is a "Privileged Content" process, which contains about:newtab. However, AMO and FxA get their own Web Content process. Different process type means different enforcement? Is this a bug?

Comment 6

[Tom Ritter [:tjr]]

(In reply to Frederik Braun [:freddy] from comment #5)

(In reply to Frederik Braun [:freddy] from comment #4)

There is a "Privileged Content" process, which contains about:newtab. However, AMO and FxA get their own Web Content process. Different process type means different enforcement? Is this a bug?

Open about:support and look at process types. Then open AMO and refresh it. You should now see a 'Privileged Mozilla Content' process which contains AMO. That's this remotetype and these domains.

Those domains should only ever be loaded in that process type; and that process type should only ever hold those domains.

separatePrivilegedMozillaWebContentProcess is the pref, it's true in Nightly/Beta but riding to release in 75.

Comment 7

[Frederik Braun [:freddy]]

I tested on Nightly.
I confirmed the "Privileged Mozilla Content" (SUMO/FxA) is different form "Privileged About" (newtab) in about:support.

The only remaining issue is a display issue in about:memory:
Privileged Mozilla Content is called "Web Content"
Privileged About is called "Privileged Content"

I will file a non-private follow-up for this.

Comment 8

[Frederik Braun [:freddy]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1627930