canmove, Confirmed users
1,220
edits
Security/Sandbox/Hardening: Difference between revisions
→Web Content (HTML, CSS, XML, SVG)
Ptheriault (talk | contribs) |
Ptheriault (talk | contribs) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 87: | Line 87: | ||
* Does all network access go through the parent (via necko)? If not, what connection are directly initiated from the child? | * Does all network access go through the parent (via necko)? If not, what connection are directly initiated from the child? | ||
* Where do origin checks occur? For example, what happens if a web resource redirects to a file:// resource? | * Where do origin checks occur? For example, what happens if a web resource redirects to a file:// resource? | ||
** Where to network security checks happen in general? | |||
* Can a compromised content process make network connections that subvert Firefox network settings (e.g.can sandbox prevent de-anonymization attacks)? | * Can a compromised content process make network connections that subvert Firefox network settings (e.g.can sandbox prevent de-anonymization attacks)? | ||
| Line 115: | Line 115: | ||
'''Open Questions'''<br> | '''Open Questions'''<br> | ||
* Communication with GPU limits the restrictions that can be placed on child process | * Communication with GPU limits the restrictions that can be placed on child process | ||
** Windows: access to GPU prevents the use of the Untrusted integrity level sandbox | |||
** OSX: To be investigated | |||
** Linux: To be investigated | |||
* IPC code (IPDL & shared memory) represents an attack surface which needs to be hardened to ensure resilience to privilege escalation attacks | * IPC code (IPDL & shared memory) represents an attack surface which needs to be hardened to ensure resilience to privilege escalation attacks | ||
* No plans yet to sandbox Compositor process | * No plans yet to sandbox Compositor process | ||
* Will Quantum render afford opportunities to limit attack surface (e.g. can we ban windows GDI usage in content process)? | * Will Quantum render afford opportunities to limit attack surface (e.g. can we ban windows GDI usage in content process)? | ||
===DOM=== | ===DOM=== | ||
| Line 139: | Line 138: | ||
===Script Execution=== | ===Script Execution=== | ||
'''Threats'''<br> | '''Threats'''<br> | ||
* JS engine presents the large attack surface | * JS engine presents the large attack surface | ||
'''Objectives''' <br> | '''Objectives''' <br> | ||
TDB | TDB | ||
| Line 165: | Line 164: | ||
'''Controls'''<br> | '''Controls'''<br> | ||
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=1305331 | |||
'''Open Questions'''<br> | '''Open Questions'''<br> | ||
| Line 207: | Line 207: | ||
* Check where the following: | * Check where the following: | ||
* HSTS | * HSTS | ||
** DoS | |||
** Child can alter entries in HSTS cache. The child must in order to process headers. See above. The child probably doesn’t have to do this, but likely can. | |||
* Key Pinning | |||
** Pin a malicious certificate to bypass protection | |||
** As above | |||
* <keygen> happens in the child, going away hopefully? | * <keygen> happens in the child, going away hopefully? | ||
* Client certificate UI? | * Client certificate UI? | ||
| Line 218: | Line 218: | ||
'''Open Questions'''<br> | '''Open Questions'''<br> | ||
* What is the process model? | * What is the process model? | ||
** What is in parent vs child? | |||
** What IPC mechanisms | |||
*** Sockets etc | |||
===Addons=== | ===Addons=== | ||
| Line 235: | Line 235: | ||
Camera/Microphone | Camera/Microphone | ||
* Requests for camera and microphone mediated by the Chrome process | * Requests for camera and microphone mediated by the Chrome process | ||
** Chrome code controls the prompt, which displays the origin of the requester to the user | |||
** Content process can lie about its origin, but user still has to approve (i.e. content process can only use the camera without user permission, if it can guess an origin that has been pre-granted access) | |||
* Camera/Microphone indicators must always be shown (content process shouldnt be able to hide them) | * Camera/Microphone indicators must always be shown (content process shouldnt be able to hide them) | ||
| Line 266: | Line 266: | ||
'''Open Questions'''<br> | '''Open Questions'''<br> | ||
* Linux? | * Linux? | ||
** Libcubeb - Audio interfacehttps://dxr.mozilla.org/mozilla-central/source/media/libcubeb/src/cubeb-internal.h#14 | |||
** Loaded in the child | |||
** Strategy: remote the audio to the parent | |||
* Mac | * Mac | ||
** CoreAudio | |||
** Microphone | |||
*** Remove access from the child | |||
*** Access only via remote functions | |||
=== Firefox Preferences === | === Firefox Preferences === | ||