Security/ProcessIsolation/ThreatModel: Difference between revisions

No edit summary
 
(18 intermediate revisions by the same user not shown)
Line 13: Line 13:
====Threats====
====Threats====
*code execution in a privileged process (inc. a library it loads) could result in direct system compromise
*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)
*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
*flaws in system services could be exploited from an isolated process
*malicious or flawed full-privilege add-ons or plugins
*malicious or flawed full-privilege add-ons or plugins
*full-privilege extension could be remotely installed without user consent
*full-privilege extension could be remotely installed without user consent
*overwrite application settings
*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==
==System / Local Network Data Theft==
Line 24: Line 30:


====Threats====
====Threats====
*a compromised privileged process would steal data from the system and local network
*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 trick a privileged process to perform an attack on its behalf (read an arbitrary file from the system or local network)
*an isolated process can still open network connections to steal data from or attack local systems (yes/no?)
*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
 
==== Assets at Risk ====
* local files, registry entries, etc.
* network files (NFS, SMB)
* intranet servers / services


==Cross-domain Compromise==
==Cross-domain Compromise==
Line 39: Line 52:
*A compromised process could persist after navigating to a different FQDN  
*A compromised process could persist after navigating to a different FQDN  
*Overwrite cached content
*Overwrite cached content
====Assets at Risk====
*Cookies and other session tokens
*Saved passwords
*Web content and data
*Cache


==Cross-domain Data Theft==
==Cross-domain Data Theft==
Line 72: Line 91:


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.
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=
=Attack Vectors=
Line 92: Line 119:


<b>Another meta-issue</b>: 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.
<b>Another meta-issue</b>: 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).
*Never patch a process that's already running
Confirmed users
717

edits