diff options
author | Daniel Clark <daniec@microsoft.com> | 2019-10-30 02:52:07 +0000 |
---|---|---|
committer | Michal Klocek <michal.klocek@qt.io> | 2020-01-16 12:16:21 +0000 |
commit | 5e753a5b1d72fb30f955ab482196b0f1a533769f (patch) | |
tree | c1612478a00c336826018f123ee9deda0c6a9380 | |
parent | 05833b160db844fd8f286fe034cb1dd1edaf8601 (diff) | |
download | qtwebengine-chromium-5e753a5b1d72fb30f955ab482196b0f1a533769f.tar.gz |
[Backport] CVE-2019-13738
Prevent sandboxed iframe Document from sharing execution context with initial about:blank Document
This change fixes an issue where a sandboxed iframe can be created such
that it contains a sandboxed Document with an opaque origin that still
shares a script context with the iframe's initial un-sandboxed
about:blank Document. The scenario is set up in the following manner:
1) Create a new iframe dynamically, and set its src to a same-domain page
that we are going to sandbox.
2) Insert the iframe into a Document, and synchronously grab a reference
to its initial about:blank Document.
3) Synchronously set iframe.sandbox = "allow-scripts" (this is still
before the same-domain page has loaded in the frame).
4) The iframe’s navigation to the same-domain page occurs, asynchronously.
FrameLoader::ShouldReuseDefaultView is called to determine the mode in
which to load the new page. FrameLoader::ShouldReuseDefaultView fails
to check the iframe’s sandbox flags (it only looks at the CSP ones),
so the navigation proceeds without resetting the type system of the
iframe. The result is that the newly loaded page shares the type
system of the initial about:blank Document.
5) Code in the sandboxed iframe is now free to make changes to its type
system that can affect any usage of the about:blank Document since
they share the same type system. This is a sandbox escape in that if
the same-domain page that the iframe is navigated to contains
user-generated code, it could run outside the iframe. It can also
result in crashes if we poke things in the right way, since an object
that should be considered cross-origin can bleed into the top-level
page, with the result that access checks which are never expected to
fail can now fail.
This change fixes the issue by making FrameLoader::ShouldReuseDefaultView()
check the iframe's sandbox flags via FrameLoader::EffectiveSandboxFlags(),
in addition to the existing check for CSP sandbox flags.
Bug: 1017441
Change-Id: I0a8ad4e156fa3053415d0578b4ffef5dc68a58e2
Reviewed-by: Michael Brüning <michael.bruning@qt.io>
-rw-r--r-- | chromium/third_party/blink/renderer/core/loader/frame_loader.cc | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/chromium/third_party/blink/renderer/core/loader/frame_loader.cc b/chromium/third_party/blink/renderer/core/loader/frame_loader.cc index 893b111979d..c56c4f347c1 100644 --- a/chromium/third_party/blink/renderer/core/loader/frame_loader.cc +++ b/chromium/third_party/blink/renderer/core/loader/frame_loader.cc @@ -1333,8 +1333,10 @@ bool FrameLoader::ShouldReuseDefaultView( // be considered when deciding whether to reuse it. // Spec: // https://html.spec.whatwg.org/C/#initialise-the-document-object - if (csp && (csp->GetSandboxMask() & WebSandboxFlags::kOrigin) != - WebSandboxFlags::kNone) { + if ((csp && (csp->GetSandboxMask() & WebSandboxFlags::kOrigin) != + WebSandboxFlags::kNone) || + ((EffectiveSandboxFlags() & WebSandboxFlags::kOrigin) != + WebSandboxFlags::kNone)) { return false; } |