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
| (10 intermediate revisions by the same user not shown) | |||
| Line 22: | Line 22: | ||
*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) | *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) | *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 32: | Line 34: | ||
*an isolated process could still open network connections to steal data from or attack local systems | *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 | *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 43: | 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 104: | 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 | |||