1587681 - WebPages can bypass FPN's webrtc checks

Status: RESOLVED FIXED

(Firefox :: Security, defect, P1)

Description

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

FPN tries to disable WebRTC by setting a bunch of properties to undefined in a content script. But page JavaScript runs before content scripts, so a page can grab WebRTC APIs before the content script gets to it just by doing:

navigator._mediaDevices = navigator.mediaDevices;
navigator._mediaDevices.__proto__._getUserMedia = navigator._mediaDevices.__proto__.getUserMedia;

I don't know how serious this is: I warned about this in August and was told that the WebRTC would be supported in 69/70 (and thus I assumed this code would be gone). But its still there as of version 0.11 so I'm filing this so it doesn't get lost.

The current checks will stop legitimate sites accidentally leak via webrtc, but a webpage which deliberately want to bypass FPN could use this (assuming that is the point of the WebRTC check in the first place).

STR:

1. enable FBN
2. Visit https://misuse.co/t/fpn/grabMediaDevices.html

Expected results:
Nothing happens (FPN should block call to getUserMedia)

Actual:
User is prompted to provide microphone access.

Comment 1

[Andrea Marchesini [:baku]]

Actually it's not a timing issue. Even this code triggers the same issue:

goButton.addEventListener("click", e => {
  navigator.mediaDevices.__proto__._getUserMedia = navigator.mediaDevices.__proto__.getUserMedia;
  navigator.mediaDevices._getUserMedia({ audio: true });
});

There is a PR for this issue. See: https://github.com/mozilla/secure-proxy/pull/702
Let me close the bug as... FIXED?

Comment 2

[Andrea Marchesini [:baku]]

Moved to github.

Comment 3

[Tom Ritter [:tjr]]

We never rated this; but we decided recently that proxy bypasses are sec-high, so adding it for historical reasons.

Comment 4

[Daniel Veditz [:dveditz]]

MOVED is OK if this actually spawned a github issue that contained the explaination from this bug. That's not what happened in this case: a PR is not an "issue". In addition, github doesn't support restricted security bugs so we shouldn't "MOVE" sec bugs to issues in any case. It's perfectly fine to call this "FIXED" by the github PR; your first instinct (comment 1) was correct.