Security/ProcessIsolation/ThreatModel: Difference between revisions

 
(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
Confirmed users
717

edits