Confirmed users
717
edits
Security/ProcessIsolation/ThreatModel: Difference between revisions
Security/ProcessIsolation/ThreatModel (view source)
Revision as of 05:42, 23 September 2009
, 23 September 2009→Cross-domain Compromise
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 | *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 | *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 | |||