Security/ProcessIsolation/ThreatModel

High Level Threat Model for Process Isolation

We need to be able to clearly understand and communicate the benefits and limitations of process isolation to users, the press and security researchers. To do so we need to identify which categories of threats we could mitigate, and then consider the implementation implications of doing so.

Major Threat Categories

In order to avoid getting bogged down by enumerating potential benefits and risks on a per-API basis, we will organize threats around broad categories, then use a few representative APIs as litmus tests of some of the implementation implications.

System Compromise

Compromise the underlying system and achieve malicious code execution with full user privileges.

Threats

• code execution in a privileged process (inc. a library it loads) could result in direct system compromise
• isolated process could trick a privileged process to perform an attack on its behalf (write a file to an arbitrary location on disk, write a registry entry, launch a process, open a socket, etc)
• flaws in system services could be exploited from an isolated process

System Data Theft

Ability to steal data from the local or network filesystem. A subset of the System Compromise category.

Cross-domain Compromise

Code originating from one FQDN can execute code (native or JavaScript) in the context of another FQDN domain without permission. This includes code from HTTP://a.com being able to execute code within HTTPS://a.com

Cross-domain Data Theft

Code originating from one FQDN can read data from another FQDN without permission.

Types of assets at risk:

• HTML
• JavaScript
• CSS?
• images
• audio/video

Session ID theft or fixation

An attacker could read or set session information. Types of information at risk:

• cookies
• local data store
• URL arguments

User interface compromise

The user interface could be compromised to trick the user into making an incorrect trust decision or directly disclose credentials or other sensitive information

Attack Vectors

Another major consideration is how the attack itself could be be delivered. In the browser, almost every component or API should be considered part of the attack surface. But for particular types of attacks (such as cross-domain attacks) its worth enumerating a set of specific assets that should be considered when evaluating the implications of cross-domain security threats, for example.

Attack vectors can be thought of in two ways:

• to enumerate what things could be used to attack the browser in the first place
• once compromised, what assets does a process have to launch further attacks

A very partial list of assets that could be considered attack vectors... please expand upon!

• HTML
• stylesheets
• .js
• images
• audio/video
• plugins
• HTTP requests and responses (headers, body)
• cookies