1040164 - Plugin container crashes result in the plugin being reloaded into the main process

Status: RESOLVED INVALID

(Core :: Security, defect)

Description

[André Reinald]

As mentioned in the below URL the plugin seems to be reloaded by the main process in case the container crashes.

While this is a very elegant fallback (it's transparent to the user), this defeats the purpose of sandboxing the container process. An unstable plugin will end up crashing the browser after it crashed the container, while a malicious one will be able to escalate privileges out of the sandbox.

Plus it's been misleading me when testing the sandbox: the testcase was working, but the container died.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Testcase:
http://mozilla.github.io/webrtc-landing/pc_test_h264.html

Steps to use the testcase (from bug 1012949 comment #43 and following):

1) Get the latest NASM source from http://www.nasm.us/ and build and install it.
2) Get the latest OpenH264 source from https://github.com/cisco/openh264.
3) Run the following commands to build OpenH264:
   a) make
   b) make gmp-bootstrap
   c) make plugin
4) Create a gmp-gmpopenh264 directory in /Library/Internet Plug-Ins/
5) Copy the following files to it from the OpenH264 build directory:
   gmpopenh264.info
   libgmpopenh264.dylib
6) Start Firefox, visit about:config, create the following boolean setting and set to true:
   media.peerconnection.video.h264_enabled
7) Quit Firefox and restart it.
8) On a machine that has a camera, load the following URL:
   http://mozilla.github.io/webrtc-landing/pc_test_h264.html
9) Click on the Start button
   After a few seconds, you will be prompted to share a camera and a microphone.  Do so.

If the testcase "works", you will find the gmp-gmpopenh264 plugin running in the plugin-container process.  But even if it "fails" (if for example the plugin-container process dies or never gets started), you'll still see your computer camera's output in the upper left corner of the frame.  I don't know what produces this output -- whether it's the OpenH264 plugin or something else.  But whatever it is, is running in the main process.  And if it's the OpenH264 plugin, we do have a potential security problem.

Comment 2

[Benjamin Smedberg]

That's not a symptom of a bug. The small rectangle is the "local" <video> which doesn't use the plugin. The large rectangle is the display of the "other side".

I don't think this is valid.

Comment 3

[André Reinald]

The clue of the problem is that the testcase works exactly the same even if the plugin container died, which hints at the plugin being loaded into the main process. Or the testcase not correctly testing the plugin.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #1)

Note that the above steps are broken on current trunk, as per bug 1012949 comment #49.

One way to work around this is to test with the 2014-07-10 mozilla-central nightly, or using a custom build with the following revision as tip:

http://hg.mozilla.org/mozilla-central/rev/1a4c6cb31743

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I think we can all agree that we need a better testcase :-(

Comment 6

[Steven Michaud [:smichaud] (Retired)]

And I just realized that you need to run the testcase maximized -- otherwise you only see one of its two frames :-(

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Actually the testcase is fine.  We just need *much* better instructions on how to use it.

When the OpenH264 plugin is running in the plugin-container process, you see camera output in both frames -- in a little box to the upper right in the right-hand frame, and in the entirety of the left-hand frame.

When (for whatever reason) the plugin-container process isn't running, you only see camera output in the right-hand frame.

I assume the OpenH264 plugin doesn't run except in the plugin-container process.  If so, this bug is invalid.

But we do have a bug if the OpenH264 plugin can run in the main process.

Comment 8

[Benjamin Smedberg]

There is no code to load it in the main process.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

See my revised STR at bug 1012949 comment #59.