Confirmed users
197
edits
Features/Security/Low rights Firefox: Difference between revisions
Features/Security/Low rights Firefox (view source)
Revision as of 22:02, 24 July 2012
, 24 July 2012no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
|Feature status=In progress | |Feature status=In progress | ||
|Feature health=OK | |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. | |Feature status note=Currently researching the situation with addons and in-process plugins while also working on implementing our proof-of-concept. | ||
}} | }} | ||
{{FeatureTeam | {{FeatureTeam | ||
| Line 13: | Line 13: | ||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|Feature open issues and risks=* Can't sandbox plugins without their cooperation (they will crash) | |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 | * 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) | * 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) | * 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 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 | |Feature users and use cases=Related bugs | ||
* Sandboxing in general: https://bugzilla.mozilla.org/show_bug.cgi?id=730956 | * Sandboxing in general: https://bugzilla.mozilla.org/show_bug.cgi?id=730956 | ||
| Line 24: | Line 25: | ||
The use case : Protect users post-exploitation without compromising their Firefox experience or deprecating any functionality. | 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. | 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 | |||
|Feature dependencies= | |||
Other references | |||
* http://www.chromium.org/developers/design-documents/sandbox | * http://www.chromium.org/developers/design-documents/sandbox | ||
* http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design | * http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design | ||
| Line 56: | Line 54: | ||
* Channel to trusted/broker/medium-privilege process | * 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 | ** 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 | ** 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. | |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) | *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) | ||
| Line 63: | Line 60: | ||
*Chrome vs Content separation aka Electrolysis/e10s | *Chrome vs Content separation aka Electrolysis/e10s | ||
*Separating access to content by domain (domains will all be handled in the same sandboxed process) | *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 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. | |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. | 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 | {{FeatureInfo | ||
| Line 82: | Line 75: | ||
{{FeatureTeamStatus | {{FeatureTeamStatus | ||
|Feature engineering status=Research | |Feature engineering status=Research | ||
|Feature engineering notes=contact imelven or mmoutenot if you would like more details on this work | |Feature engineering notes=contact imelven or mmoutenot if you would like more details on this work | ||
}} | }} | ||