1587508 - Web pages can automatically turn off FPN

Status: VERIFIED FIXED

(Firefox :: Security, defect, P1)

Description

[Rob Wu [:robwu]]

FPN runs a content script on every website, whose purpose is to intercept WebRTC API requests, and inform the user that the functionality does not work when FPN is enabled. The rendered UI has a button to turn off FPN, which can be abused to automatically disable FPN without user interaction.

STR:

1. Install FPN and sign in to activate it.
   ( I'm not in the US, so I actually ran from the source at https://github.com/mozilla/secure-proxy and patched it to simulate being logged in).
2. Visit https://example.com (https URL because WebRTC is only available on https).
3. Run the following snippet from the devtools console in the tab from step 2:

navigator.mediaDevices.getSupportedConstraints();
setTimeout(() =>{ document.getElementById("exempt").click() }, 1000);

The test case forces the extension to shows a modal to inform the user that FPN may interfere with the functionality of the site: https://github.com/mozilla/secure-proxy/blob/e0a76f9e008afcb5ac01e2c10564393cddce0d07/src/content/content-script.js#L156-L168
... and then it clicks on the "exempt" button to disable FPN.

Web pages should not be able to disable FPN, especially not without user interaction. The least that one can do is to check event.isTrusted before processing the click event. That however still enables web pages to use CSS to turn the button in a big transparent overlay, which can be used to trick users into clicking the button anyway.
To properly fix the bug, the modal dialog's content should be resilient against manipulation by the main page, e.g. by rendering the content in an iframe that cannot be accessed by web pages.

Comment 1

[:Gijs (he/him)]

Gah, I thought we learned from screenshots that this was a bad idea? :-\

bug 1340930 is the tracking bug for a sane API for add-ons to do in-content things in ways that cannot be meddled with by the website.

Comment 2

[Tom Ritter [:tjr]]

Rob, Arthur - for assigning critically; can either of you tell us if this disables FPN for the specific site or if it disables FPN entirely for all sites?

Comment 3

[Rob Wu [:robwu]]

The "exempt" feature referenced in the bug report applies to the calling tab only. If another URL is loaded in that tab, FPN will still be disabled for that load. If the tab is closed, the exception is forgotten.

Comment 4

[Kris Maglione [:kmag]]

(In reply to :Gijs (he/him) from comment #1)

Gah, I thought we learned from screenshots that this was a bad idea? :-\

bug 1340930 is the tracking bug for a sane API for add-ons to do in-content things in ways that cannot be meddled with by the website.

Even without that, the existing normal way to handle these situations is to have the content script create an iframe with an origin that the page content can't access (probably ideally in the shadow DOM), and host all of its sensitive UI in that.

In any case, this isn't a WebExtensions bug. It's a bug in a particular extension. I'm not sure what component it belongs in, though.

Comment 5

[Johann Hofmann [:johannh]]

We decided to put security bugs for FPN into Core::Networking for now. This is not a WebExtension bug, indeed.

The easy alternative that I (unsuccessfully) tried to pitch was just showing a native Firefox doorhanger on pages instead of an in-content modal. This is possible because the extension has access to privileged code. The counter-argument has always been that "the WebRTC issue is just temporary for our Beta and will very soon be fixed on Necko side", that an in-content modal would just be the quicker solution and that real paid users will never see it because we'll fix the underlying issue before the roll-out.

Dragana, Honza, do we know for how much longer this workaround needs to be in place? If this is going to take much longer, we should consider a chrome doorhanger again.

Comment 6

[Johann Hofmann [:johannh]]

This is also relevant when looking at bug 1587681. If we don't have proxy support for WebRTC soon we need a more general restructuring of the way that the extension handles WebRTC connections. (i.e. by disabling the webrtc pref while it's active)

Comment 7

[Honza Bambas (:mayhemer)]

This bug does belong to Networking. The fix has to happen either in the addon (to use a different chrome UI element/widget) or in how the web extension back end shows the used notification widget, if nothing else can be used.

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to Johann Hofmann [:johannh] from comment #5)

Dragana, Honza, do we know for how much longer this workaround needs to be in place? If this is going to take much longer, we should consider a chrome doorhanger again.

You need to ask :bwc, because this is not a necko issue, this is a webrtc issue that is tracked in a different component.

Comment 9

[Johann Hofmann [:johannh]]

This bug does belong to Networking. The fix has to happen either in the addon (to use a different chrome UI element/widget) or in how the web extension back end shows the used notification widget, if nothing else can be used.

The main point is to have a component that is home to these issues (because GitHub doesn't support private bug reporting), but let's move it to Firefox::Security then.

:bwc, see comment 5, thank you!

Comment 10

[Byron Campen [:bwc]]

Last time I checked, webrtc was working fine with FPN.

Comment 11

[Andrea Marchesini [:baku]]

(In reply to Byron Campen [:bwc] from comment #10)

Last time I checked, webrtc was working fine with FPN.

In nightly, correct? Not in release.

Comment 12

[Andrea Marchesini [:baku]]

Plus, even if we support 70/71, secure-proxy should run with 68.0.1 too. So, we need the modal for 68 and 69 (and I suspect 70 too)

Comment 13

[Byron Campen [:bwc]]

(In reply to Andrea Marchesini [:baku] from comment #11)

(In reply to Byron Campen [:bwc] from comment #10)

Last time I checked, webrtc was working fine with FPN.

In nightly, correct? Not in release.

Right.

Comment 14

[Andrea Marchesini [:baku]]

The current plan is to create an iframe for the webRTC dialog. See: https://github.com/mozilla/secure-proxy/issues/705

Comment 15

[Tom Ritter [:tjr]]

We decided recently that proxy bypasses are sec-high.

Comment 16

[Daniel Veditz [:dveditz]]

This one was a better candidate for MOVED status than bug 1587681 because we did file a github issue, but I don't think we should have for a security bug. At least the issue there doesn't go into the core of the problem so it's fine as a placeholder.

Let's leave this OPEN until we land a PR for issue #705 and then call this FIXED.

Comment 17

[Liz Henry (:lizzard)]

Johann, did this make it into the product or is that yet to happen?

Comment 18

[Johann Hofmann [:johannh]]

This was solved to the best of our abilities, given the short time frame, by using Shadow DOM inside the content script. While it does not prevent more sophisticated methods like click-jacking, it'll hold until 71 is out. As things stand FPN doesn't seem go out of Beta before that anyway.

Comment 19

[Bogdan Surd, QA [:bsurd, NI]]

Verified as fixed with the latest release and esr versions. A modal is displayed asking the user if he would like to turn off FPN or keep it on. This is not applicable for FF 71+ as WebRTC is properly supported from those versions.