Electrolysis/Plugins Security Review

Overview

Separate plugins into different processes (one process per plugin library) from Firefox so that crashes or other instability caused by plugin code does not cause Firefox to become unusable. A side benefit may be better parallelism and performance on multi-core machines.

Background links

• tracking bug tree
• MDC:Plugins/Multi-Process Plugin Architecture

Security and Privacy

Is this feature a security feature? If it is, what security issues is it intended to resolve? 

It is not primarily intended as a security feature, although it may provide some limited benefits by isolating the plugin process memory.

What potential security issues in your feature have you already considered and addressed? 

The IPDL message subsystem is designed to strictly check message passing semantics between processes and abort the plugin subprocess when unexpected behavior and bad values in messages are detected.

Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? 

If the main IPC preference is missing, the plugin host falls back to loading all plugins in-process.

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

Because plugins already have complete binary access to the system, the main concern is providing the plugin with the same data that they currently use to make trust decisions. This should be completely transparent to the plugin. For example, many plugins rely on getting the page URL to make trust decisions (many plugins even give full local privileged access to certain pages) and implement XSS protections. We need to make sure that the described mechanisms and other mechanisms in use still work or at least fall back to the secure mode.

Running plugins in their own processes means that plugins each have their own thread of control, in addition to the browser's. This can lead to race conditions between the plugin and browser process, and the host code must resolve them.

• How are transitions in/out of Private Browsing mode handled?

Transitions are passed to the plugin in the same way as currently handled with in-process plugins.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

There are no exported APIs beyond the existing NPAPI/NPRuntime interfaces which are reflected into the plugin process.

There is additional UI only if the plugin process crashes: in this case we have a plugin-crashed binding or notification bar which prompts the user to reload.

• Does it interoperate with a web service? How will it do so?

Plugin crashes are submitted to the existing crash submission architecture. Plugin crashes are submitted by the browser process and don't display the crash-report-submitter application which appears when the browser process crashes.

• Explain the significant file formats, names, syntax, and semantics. N/A

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully? yes

• Does it change any existing interfaces?

I believe we made one additive change on mozilla-central, nsIObjectLoadingContent.pluginCrashed. On the 1.9.2 this will be put on an extended interface to avoid changes to existing interfaces.

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)?

The OOPP code is very self-sufficient: in most cases we attempted to write code without modifying the plugin host at all. In a few cases we fixed bugs in the plugin host or added features for crashed plugins. But there are very few external dependencies.

Data

• What data is read or parsed by this feature?
• What is the output of this feature?
• What storage formats are used?

As far as I know, there are no data formats.

Reliability

• What failure modes or decision points are presented to the user?

The UI tries to avoid presenting any decisions to the user. Crash reports are submitted automatically, and the user has the option to disable this feature in the application preferences. The hang detector also runs automatically and kills the plugin process if it doesn't respond (current timeout 10 seconds).

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

There are no files. Currently we believe the IPDL message-passing mechanism cleans up locks and the RPC stack correctly in crash conditions.

There are two known bugs where crash or failure to launch during startup cause lockups, and where crash during shutdown may cause problems: both are filed.

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

The setting whether to submit crash reports is exposed in the Firefox preferences panel. Settings whether to enable out of process plugins (in general or for particular plugins) are available in about:config/arbitrary prefs. The hang detector timeout can be changed/disabled using about:config as well.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

Yes, --disable-ipc removes OOPP support.

• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

N/A, I think.

Relationships to other projects

Are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

nspluginwrapper implements a similar strategy of remoting to load 32-bit plugins in 64-bit browsers. We do not depend on their work; IPDL provides a much safer message-passing platform. nspluginwrapper also doesn't support Windows and OS X. Opera uses nspluginwrapper on Linux.

The Java plugin runs its virtual machine in a separate process, presumably for similar reasons as nspluginwrapper's and ours. We depend on it indirectly, only in that it's an NPAPI plugin.

Google chrome also implements multi-process plugins. Our design was inspired from theirs, with the addition of IPDL for protocol safety.

• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

The basic process launching, I/O and serialization/deserialization code was imported from the Google Chromium codebase. It has been significantly altered and we plan on rewriting or removing it in future versions. There is not a plan at this time to re-unify the code with Chromium.

Review comments