1074561 - Allow non-EME GMPs (e.g., OpenH264) to run on non-sandbox-capable Linux

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

We've reevaluated the security implications of allowing Linux hosts without seccomp-bpf support to run OpenH264 unsandboxed.  The plugin itself isn't considered untrusted as with EME; it's open source modulo patent issues, so it could be audited by anyone with the resources to do so; it has been subjected to fuzz testing; and if a chemspill of the plugin is ever necessary, it can be done without updating the browser.  (Also, anything that can use WebRTC can necessarily run script, which exposes a vastly larger attack surface than OpenH264.)

(This is paraphrased from :jesup via IRC; anything I might have mis-summarized should be corrected.)

A change to make GMP sandboxing on Linux best-effort should be small enough to be safe for beta, even at this late stage.  The other part of this — disabling EME in the absence of sandboxing — won't need uplift to branches that won't be able to load an untrusted CDM.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Step 1: Allow Gecko Media Plugins to run unsandboxed.

printf_stderr might not be the best approach for logging, but I'd like for this condition not to be completely silent, even on non-debug builds.

As mentioned previously, this patch is separated in order to allow for lower-risk uplift.  We won't have any media plugins that require sandboxing until the 36 branch, so the intermediate state between this and the next patch isn't a security problem.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=782215c24130

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Step 2: Prevent EME plugins from being loaded or used on non-sandbox-capable Linux.

This patch prevents loading any media plugin declaring the "eme-decrypt" API, and also causes GeckoMediaPluginService::GetGMPDecryptor to fail, on Linux systems that can't support sandboxing.

Tested locally with MOZ_FAKE_NO_SANDBOX — H.264 WebRTC works, but the content/media/test/test_encryptedMediaExtensions.html mochitest fails.

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=82b264c94fd2

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8497704 [details] [diff] [review]
Step 1: Allow Gecko Media Plugins to run unsandboxed.

Review of attachment 8497704 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/media/gmp/GMPChild.cpp
@@ +265,5 @@
>    // this process's execution hasn't been affected by its content yet.
> +  if (mozilla::CanSandboxMediaPlugin()) {
> +    mozilla::SetMediaPluginSandbox(nativePath.get());
> +  } else {
> +    printf_stderr("GMPChild::LoadPluginLibrary: Loading media plugin %s unsandboxed.\n",

unusual, but ok

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6da176806a99
https://hg.mozilla.org/integration/mozilla-inbound/rev/1cdfd9838770

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Comment on attachment 8497704 [details] [diff] [review]
Step 1: Allow Gecko Media Plugins to run unsandboxed.

Approval Request Comment

[Feature/regressing bug #]: Bug 1043733

[User impact if declined]: For approximately 4% of Linux desktop users (on the order of several hundred thousand profiles), OpenH264 will silently fail to load.  This would break interoperability with WebRTC implementations that support H.264 but not VP8, and it for Loop/Hello calls with the other end on FxOS it would reduce battery life and possibly call quality (no hardware assist for VP8).  The user would not have a clear indication of what is happening or why.

[Describe test coverage new/current, TBPL]: Existing tests for OpenH264 and the clear-key CDM, running on TBPL, cover the case where sandboxing is supported (corresponding to ~96% of Linux desktop users).  I've tested locally with an option (the MOZ_FAKE_NO_SANDBOX environment variable) that simulates a lack of sandboxing support, and the results are as expected.

[Risks and why]: Minimal.  For the 96% where mozilla::CanSandboxMediaPlugin() returns true, a visual inspection of this patch shows that there will be no change.  For the 4% where it's false, the only effect that that has after this patch (compared to the true case) is to skip sandbox initialization.

[String/UUID change made/needed]: None.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Try on aurora: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=19f7605b21d2
Try on beta: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=fdd3e4cc75c5

There's some starred breakage because of e10s tests run on branches where it's not expected to work, b2g tests on branches that aren't used for b2g, and a couple of the usual intermittents.  They should all be starred appropriately.

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6da176806a99
https://hg.mozilla.org/mozilla-central/rev/1cdfd9838770

Comment 8

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Part 1, backported to mozilla-beta.

There are context changes between aurora and beta such that attachment 8497704 [details] [diff] [review] doesn't apply cleanly to beta; attaching a backported patch.  Diffing the patches confirms they're they same change.

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3b859b93de23
https://hg.mozilla.org/releases/mozilla-beta/rev/583cc1307044

Comment 10

[Bogdan Maris, Desktop QA]

I used Debian 7.6 in Virtual Box for testing. When I made a h246 call using http://mozilla.github.io/webrtc-landing/pc_test.html demo the webcam shows blank video. 
Here are the logs for all builds I tested, Firefox 33.0RC, latest Aurora and latest Nightly: https://pastebin.mozilla.org/6742343

Should this be a problem? I`ve tested the webcam on other websites and it works just fine.

Comment 11

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #10)
> I used Debian 7.6 in Virtual Box for testing. When I made a h246 call using
> http://mozilla.github.io/webrtc-landing/pc_test.html demo the webcam shows
> blank video. 

Did the fake video (the changing color with the black dots at the top) appear in the large right-hand video element, or only the small left-hand “self view” element?  That should show whether the codec is working, independently of whether the virtual machine's camera (the small video on the right and the large video on the left) works.

Also, I think the test case dom/media/tests/mochitest/test_peerConnection_basicH264Video.html should cover this, but I'm not familiar enough with the WebRTC side of this to know how much of the functionality it tests.

> Here are the logs for all builds I tested, Firefox 33.0RC, latest Aurora and
> latest Nightly: https://pastebin.mozilla.org/6742343
> 
> Should this be a problem? I`ve tested the webcam on other websites and it
> works just fine.

Are those sites using getUserMedia or some other method (like Flash)?

Comment 12

[Bogdan Maris, Desktop QA]

(In reply to Jed Davis [:jld] from comment #11)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #10)
> > I used Debian 7.6 in Virtual Box for testing. When I made a h246 call using
> > http://mozilla.github.io/webrtc-landing/pc_test.html demo the webcam shows
> > blank video. 
> 
> Did the fake video (the changing color with the black dots at the top)
> appear in the large right-hand video element, or only the small left-hand
> “self view” element?  That should show whether the codec is working,
> independently of whether the virtual machine's camera (the small video on
> the right and the large video on the left) works.

Yes, both fake videos (changing color ones) appear on the page, so this should indicate that the codec works as expected, right?

> Also, I think the test case
> dom/media/tests/mochitest/test_peerConnection_basicH264Video.html should
> cover this, but I'm not familiar enough with the WebRTC side of this to know
> how much of the functionality it tests.
> 
> > Here are the logs for all builds I tested, Firefox 33.0RC, latest Aurora and
> > latest Nightly: https://pastebin.mozilla.org/6742343
> > 
> > Should this be a problem? I`ve tested the webcam on other websites and it
> > works just fine.
> 
> Are those sites using getUserMedia or some other method (like Flash)?

I tested on sites with Flash, but today I checked on other getUserMedia demos and I get the same output there, blank pages on webcam, same result on Chromium so must be something from VirtualBox or Debian.

Comment 13

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #12)
> Yes, both fake videos (changing color ones) appear on the page, so this
> should indicate that the codec works as expected, right?
[...]
> I tested on sites with Flash, but today I checked on other getUserMedia
> demos and I get the same output there, blank pages on webcam, same result on
> Chromium so must be something from VirtualBox or Debian.

In that case, I'd say that the patch is working correctly, and it's just a camera issue with the VM.

Comment 14

[Bogdan Maris, Desktop QA]

(In reply to Jed Davis [:jld] from comment #13)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #12)
> > Yes, both fake videos (changing color ones) appear on the page, so this
> > should indicate that the codec works as expected, right?
> [...]
> > I tested on sites with Flash, but today I checked on other getUserMedia
> > demos and I get the same output there, blank pages on webcam, same result on
> > Chromium so must be something from VirtualBox or Debian.
> 
> In that case, I'd say that the patch is working correctly, and it's just a
> camera issue with the VM.

Thanks Davis, marking this as verified fixed.