Features/Security/Low rights Firefox

Status

Team

Open issues/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)

Stage 1: Definition

1. 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.

2. Users & 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.

3. 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

4. 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

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)

Stage 2: Design

5. Functional specification

See the Chromium sandbox design document : http://www.chromium.org/developers/design-documents/sandbox

6. User experience design

`

Stage 3: Planning

7. 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.

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes