diff options
Diffstat (limited to 'chromium/docs/security')
| -rw-r--r-- | chromium/docs/security/OWNERS | 1 | ||||
| -rw-r--r-- | chromium/docs/security/compromised-renderers.md | 29 | ||||
| -rw-r--r-- | chromium/docs/security/sheriff.md | 11 | ||||
| -rw-r--r-- | chromium/docs/security/side-channel-threat-model.md | 28 |
4 files changed, 59 insertions, 10 deletions
diff --git a/chromium/docs/security/OWNERS b/chromium/docs/security/OWNERS index e30cc23542f..1ea372401d2 100644 --- a/chromium/docs/security/OWNERS +++ b/chromium/docs/security/OWNERS @@ -6,6 +6,7 @@ felt@chromium.org mmoroz@chromium.org nasko@chromium.org meacer@chromium.org +mkwst@chromium.org palmer@chromium.org parisa@chromium.org rsesek@chromium.org diff --git a/chromium/docs/security/compromised-renderers.md b/chromium/docs/security/compromised-renderers.md index 6733e1384e6..5b21ec9ebb6 100644 --- a/chromium/docs/security/compromised-renderers.md +++ b/chromium/docs/security/compromised-renderers.md @@ -245,9 +245,13 @@ Compromised renderers shouldn't be able to poison the JavaScript code cache used by scripts executed in cross-site execution contexts. Protection techniques: -- Partitioning the code cache by Network Isolation Key (NIK). -- Using `CanAccessDataForOrigin` in +- Validating origins sent in IPCs from a renderer process by using + `CanAccessDataForOrigin` in `CodeCacheHostImpl::DidGenerateCacheableMetadataInCacheStorage`. +- Using trustworthy, browser-side origin lock while writing to and fetching from + the code cache by using `ChildProcessSecurityPolicyImpl::GetOriginLock` in + `GetSecondaryKeyForCodeCache` in + `//content/browser/renderer_host/code_cache_host_impl.cc` ## Cross-Origin-Resource-Policy response header @@ -384,3 +388,24 @@ below. processes on Android (for example affecting protections of CORB, CORP, Sec-Fetch-Site and in the future SameSite cookies and Origin protections). See also https://crbug.com/891872. + + +## Renderer processes hosting DevTools frontend + +If an attacker could take control over the DevTools frontend then the attacker +would gain access to all the cookies, storage, etc. of any origin within the +page and would be able to execute arbitrary scripts in any frame of the page. +This means that treating the DevTools renderer as untrustworthy wouldn't in +practice offer additional protection for the same-origin-policy. + +Because of the above: + +- Chrome ensures that the DevTools frontend is always hosted in a renderer + process separate from renderers hosting web origins. +- Chrome assumes that the DevTools frontend is always trustworthy + (i.e. never compromised, or under direct control of an attacker). + For example, when the DevTools process asks to initiate a HTTP request on + behalf of https://example.com, the browser process trusts the DevTools + renderer to claim authority to initiate requests of behalf of this origin + (e.g. attach SameSite cookies, send appropriate Sec-Fetch-Site request header, + etc.). diff --git a/chromium/docs/security/sheriff.md b/chromium/docs/security/sheriff.md index 897fa7a5cd9..c4418c980fe 100644 --- a/chromium/docs/security/sheriff.md +++ b/chromium/docs/security/sheriff.md @@ -248,11 +248,12 @@ the assessment? Be especially on the lookout for Highs that are really Criticals, and Lows that are really Mediums (make sure to account for process types and sandbox boundaries). -For V8 issues, it can be hard to identify the correct security severity. If -you're not sure, please take your best guess, and add the -`Security_Needs_Attention-Severity` label alongside the regular -`Security_Severity-*` label. If you do this, the V8 team will check the -severity later and change it if necessary. +For V8 issues, it can be hard to identify the correct security severity. +Always set the severity to High unless there's strong evidence of an obvious +mitigation. Please add the `Security_Needs_Attention-Severity` label alongside +the regular `Security_Severity-*` label. If the bug is not exploitable, or is +mitigated, the V8 team will reduce the security severity (to avoid unnecessary +risk of merging the bug into stable branches). #### Step 3. [Label, label, label](security-labels.md). diff --git a/chromium/docs/security/side-channel-threat-model.md b/chromium/docs/security/side-channel-threat-model.md index 05f34b035bf..888baad3ce9 100644 --- a/chromium/docs/security/side-channel-threat-model.md +++ b/chromium/docs/security/side-channel-threat-model.md @@ -341,12 +341,34 @@ clocks, and we want the OWP to be able to support them. ### Gating Access To APIs That Enable Exploitation +We want to support a powerful web, though we recognize that some kinds of APIs +a powerful web requires are more likely than others to facilitate exploitation, +either because they can be used as very high-resolution timers +(`SharedArrayBuffer`), or because they provide powerful introspection +capabilities (`performance.measureMemory`). We can mitigate the risks these APIs +pose by exposing them only in contexts that have opted-into a set of +restrictions that limits access to cross-origin data. + +In particular, [`Cross-Origin-Opener-Policy` (COOP) and +`Cross-Origin-Embedder-Policy` (COEP)](https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit) +seem promising. Together, these mechanisms change web-facing behavior to enable +origin-level process isolation, and ensure that cross-origin subresources will +flow into a given process only if they opt-into that usage. These properties +give us a higher degree of confidence that otherwise dangerous APIs can be +exposed safely, as any attack they enable would only gain access to same-origin +data, or data that explicitly asserted that it accepted the risk of exposure. + +Both COOP and COEP are enabled as of M83, and we [plan to require both before +enabling APIs like `SharedArrayBuffer`](https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0MEXs6TJhg/F0UduPfpAQAJ). +Other browsers seem likely to do the same. + +#### Other Gating Mechanisms + **Note:** This section explores ideas but we are not currently planning on implementing anything along these lines. -Although we want to support applications that necessarily need access to -features that enable exploitation, such as `SharedArrayBuffer`, we don’t -necessarily need to make the features available unconditionally. For example, a +Looking beyond developer opt-ins such as COOP and COEP, we might be able to find +other ways of limiting the scope of APIs to reduce their risk. For example, a third-party `iframe` that is trying to exploit Spectre is very different than a WebAssembly game, in the top-level frame, that the person is actively playing (and issuing many gestures to). We could programmatically detect engagement and |