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)
• a restricted process must lower privilege effectively after boostrapping, and close any open privileged resources beforehand
• if low privilege content has access to, or provides input directly to, drivers such as video, printing, storage, fonts, etc. there is a significant risk that those device drivers are not designed to consume malicious / untrusted content

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
• theft of local and network files via file:// and related schemes
• theft of local data via direct access to database or database files

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.

Threats

• Manipulate clipboard
• Manipulate deskop, display settings, etc
• Render or intercept native OS or other-app dialogs
• Applications on the same desktop could defacto share a security context via windows messages (http://dev.chromium.org/developers/design-documents/sandbox#TOC-The-alternate-desktop)

More info here: http://dev.chromium.org/developers/design-documents/sandbox#TOC-The-Job-object

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.

Plugins

Plugins are not planned to be sandboxed yet, since they require their own broker architecture, mostly due to challenges around:

- filesystem access (file uploads, downloads, media playback) - auto-update - potentially registry and network access (binary sockets, etc) - or allow them unlimited access

General pitfalls

• Some Windows processes don't respect token privileges, they clone their own token based upon the user with default permissions (task manager is an example)
• Some services allow anyone to talk to them regardless of restrictions (Telnet service for example)
• There are a lot of DLLs in Windows that inject themselves into a process (like renderer) that can't deal with restricted rights tokens, so they crash or behave inappropriately (leave handles open, etc).