View source for Features/Security/Low rights Firefox

{{FeatureStatus
|Feature name=Low-rights Firefox (whole process sandbox)
|Feature stage=Definition
|Feature status=In progress
|Feature health=OK
|Feature status note=Currently researching the situation with addons and in-process plugins while also working on implementing our proof-of-concept.
}}
{{FeatureTeam
|Feature product manager=Sid Stamm
}}
{{FeaturePageBody
|Feature open issues and risks=* Can't sandbox plugins without their cooperation (they will likely crash when they try to access something that the sandbox restricts access to)
* Firefox runs the NPAPI part of the Java plugin in process (see bug https://bugzilla.mozilla.org/show_bug.cgi?id=603417) This piece of the plugin then launches separate processes and uses the in-process bit of the plugin as a communication channel to the browser.
* Binary add-ons that try to access sandboxed resources directly (not via XPCOM) such as the filesystem will probably crash
* Some percentage of XPCOM add-ons will need updating (currently being researched)
* Need to research how to implement broker API's for certain operations (filesystem, some networking, device access, maybe WebGL and some audio/video)
|Feature overview=We can obtain a lot of security benefit by implementing a whole-process sandbox which will run an instance of Firefox.exe in a sandbox, reducing the runtime privileges of the entire Firefox process. An instance of Firefox with normal user privileges is started by the user, this then launches another instance of Firefox which drops privileges and actually runs the content and chrome of the browser.
|Feature users and use cases=Related bugs
* Sandboxing in general: https://bugzilla.mozilla.org/show_bug.cgi?id=730956
* OS X 10.5 Sandbox: https://bugzilla.mozilla.org/show_bug.cgi?id=387248
* Use seccomp to sandbox on Linux : https://bugzilla.mozilla.org/show_bug.cgi?id=742434

The use case : Protect users post-exploitation without compromising their Firefox experience or deprecating any functionality. 

Core assumption : The sandbox is intended to mitigate post exploitation, threats ie when complete control of the sandboxed process has been taken by the attacker via the successful exploitation of a vulnerability, including avoiding all other OS level mitigations such as ASLR, stack protection, etc. In this situation, the Firefox.exe process containing the vulnerable code is completely compromised and the attacker can do anything that process (by default, really meaning the user running Firefox) is allowed to do.
|Feature dependencies=Other references
* http://www.chromium.org/developers/design-documents/sandbox
* http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design
* https://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-part-1-design.html
* https://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-%E2%80%93-part-2-%E2%80%93-the-sandbox-process.html
* http://msdn.microsoft.com/en-us/library/bb250462%28v=vs.85%29.aspx
* http://msdn.microsoft.com/en-us/library/bb625964.aspx
|Feature requirements=Protect users against the following threats to whatever degree we can : 

* Local Filesystem/Registry Read
** A compromised Firefox can read any file or registry key/value that the Firefox user has access to - this includes stealing their cookies, local storage, saved passwords and other private information for all sites as well as reading the user's browser history 
* Local Filesystem/Registry Write
** A compromised Firefox can write any file or registry key/value that the Firefox user has access to - this includes modifying Firefox's trusted SSL certificates and Firefox settings, which could affect product updates, network proxies, or other bits of security or privacy sensitive browser configuration. Other threats includes poisoning the browser's network cache or HTML5 appcache 
* Launch New Processes
** A compromised Firefox could launch additional malicious processes to possibly escalate the attacker's privilege or attempt to make the compromise more permanent 
* Network Access (including remote filesystem access)
** A compromised Firefox can send and receive network traffic - this can be used to attack and exploit other hosts, including hosts only reachable from the internal network where the compromised Firefox is running. This can also be used as a command and control channel or to download additional post-exploitation payloads or instructions or to exfiltrate data from the compromised system. 
* Loading additional libraries into content process
** A compromised Firefox can load additional libraries into the compromised content process - these could be used to snoop on the user or steal passwords or cookies.
** The existing DLL blocklist is a small amount of mitigation here, but this can be worked around easily by changing the DLL name, for example.
** This requires that either the attacker places libraries on the target machine via the compromised process' ability to write to the filesystem or dynamically modifies the content process' memory to install hooks 
* IPC (shared memory / window messages) based attacks against other processes
** A compromised Firefox can send Windows messages to privileged applications on the same desktop vulnerable to these types of attacks to elevate privileges
** A compromised Firefox can write to shared memory accessible to its process, potentially conducting attacks against other processes 
* Kernel mode attack surface - WebGL, other OS graphics API's
** A compromised Firefox can make syscalls or call any WebGL or OS supplied graphics API (when they are implemented in kernel mode drivers) - these drivers or the kernel may contain vulnerabiliities allowing escalation to ring 0/kernel level privileges 
* Channel to trusted/broker/medium-privilege process
** A sandboxed content process needs a channel to the trusted/higher privilege process to perform sensitive operations - this channel itself may contain exploitable implementation flaws
** Proxy/broker APIs either need to be totally harmless or to have some way of validating the arguments that are passed to them - remoting the call to the broker process doesn't add any security if a compromised process can do what it wants by simply calling exposed API's in the broker
|Feature non-goals=*Cross-domain and other intra-browser attacks (browsing history, passwords, cookies, etc) will not be mitigated.
*Plugins will not be sandboxed as they cannot be run in low rights without their cooperation (ie. code changes) and may have their own sandbox (e.g. Flash)
*Sandboxing on non-Windows platforms (at first - sandboxing on Linux is being researched as part of work of B2G, and there is interest in using the OSX sandbox as well)
*Chrome vs Content separation aka Electrolysis/e10s
*Separating access to content by domain (domains will all be handled in the same sandboxed process)
|Feature functional spec=See the Chromium sandbox design document : http://www.chromium.org/developers/design-documents/sandbox
|Feature implementation plan=Right now we are focused on researching the issues with running Java out-of-process and finding out what APIs the top 100 addons on addons.mozilla.org use and how they use them. Our goal is to understand possible approaches to working around or solving these problems with respect to sandboxing the Firefox.exe process without needing to have a whitelist so permissive that it has an extremely diluted security benefit.

Additionally, we are working on a proof-of-concept implementation of a build of Firefox that runs in a low-right, sandboxed process, using the Chromium sandbox library.
}}
{{FeatureInfo
|Feature priority=P3
|Feature theme=Product Hardening
|Feature roadmap=Security
|Feature secondary roadmap=Platform
|Feature list=Platform
|Feature engineering team=Security
}}
{{FeatureTeamStatus
|Feature engineering status=Research
}}