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) - beware proxy APIs in brokers/elevated privilege processes
• flaws in system services could be exploited from an isolated process
• malicious or flawed full-privilege add-ons or plugins
• full-privilege extension could be remotely installed without user consent
• overwrite application settings
• process could import an external library and call its functions
• process could take advantage of race conditions to modify a system call / message between the time a security check is performed and the API is actually called
• process could take advantage of interprocess communications to executed code within an elevated context (see: http://en.wikipedia.org/wiki/Shatter_attack for an example)
• different resources or types of file systems may not be protected from direct access by low-privilege processes, due to lack of support for security descriptors (ex. FAT and FAT32: http://dev.chromium.org/developers/design-documents/sandbox#TOC-The-token)

System / Local Network Data Theft

Ability to steal data from the system or local network (i.e. direct network attacks). A subset of the System Compromise category.

Threats

• a compromised privileged process could directly steal data from the system and local network
• an isolated process could trick a privileged process to perform an attack on its behalf (read an arbitrary file from the system or local network)
• an isolated process could still open network connections to steal data from or attack local systems
• an isolated process could behave like a keylogger to capture input for other tabs or FQDNs

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 inject code into HTTPS://a.com

Threats

• Cross-domain assets that are not isolated to their own domain process could compromise another domain's process
• Even a limited privilege add-on or plugin could inject code into an arbitrary domain if malicious, or inadvertently become an agent for cross-domain attacks if it contains a security flaw
• Imported cross-domain access could contain JavaScript (i.e. <SCRIPT>, XBL in CSS)
• A compromised process could persist after navigating to a different FQDN
• Overwrite cached content

Cross-domain Data Theft

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

Threats

• a compromised isolated process could use cross-domain assets accessible from within its own process to steal data from other domains (i.e. cross-domain images, style sheets, scripts, iframes, etc.)
• compromised process maybe able to read the DOM of another FQDN

Assets at Risk

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

Session ID Theft or Fixation

An attacker could read or set session information for another domain.

Threats

• An isolated process could read or set cookies for a different FQDN
• If non-SSL sites are not isolated, it may be impossible to determine which domain is making a cookie setting request (this may or may not be a problem)

Assets at Risk

• cookies
• local data store
• URL arguments
• plugins' data stores

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, or install malicious extensions or applications.

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 its still worth enumerating a set of a potential attack vectors to help frame discussions in more concrete terms.

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 access to for launching 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

Another meta-issue: if we don't isolate non-SSL domains from each other, do we create a potential "cesspool", making it impossible to determine the origin of a given non-SSL request, and makes it difficult to police SSL and non-SSL interactions? Clearly we don't really trust the origin of any non SSL request anyway. But are there any situations where a non-SSL domain has elevated privileges compared to other domains when interacting with its SSL counterpart? This could have implications for HTTP content loading HTTPS assets, for example, and vice versa.