Closed Bug 1453339 Opened 6 years ago Closed 6 years ago

Assertion failure: js::GetObjectCompartment(aGlobal->GetGlobalJSObject()) == js::GetObjectCompartment(aPromiseObj), at /builds/worker/workspace/build/src/dom/promise/Promise.cpp:450

Categories

(Core :: DOM: Core & HTML, defect)

59 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla61
Tracking Status
firefox-esr52 60+ verified
firefox59 --- wontfix
firefox60 + verified
firefox61 + verified

People

(Reporter: jkratzer, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, sec-other, testcase, Whiteboard: [adv-main60-][adv-esr52.8-][post-critsmash-triage])

Attachments

(3 files)

Attached file trigger.html —
Testcase found while fuzzing mozilla-central rev f6c3a0a19d82.

rax = 0x0000000000000000   rdx = 0x0000000000000000
rcx = 0x00007f9eaab5c2dd   rbx = 0x00007f9e89c5b0d0
rsi = 0x00007f9eaae2b770   rdi = 0x00007f9eaae2a540
rbp = 0x00007ffd611a3f10   rsp = 0x00007ffd611a3ee0
r8 = 0x00007f9eaae2b770    r9 = 0x00007f9eabef5740
r10 = 0x0000000000000039   r11 = 0x0000000000000000
r12 = 0x00007ffd611a40e8   r13 = 0x00007ffd611a3f88
r14 = 0x00007ffd611a41a0   r15 = 0x00007ffd611a40d8
rip = 0x00007f9e9aac804d
OS|Linux|0.0.0 Linux 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018 x86_64
CPU|amd64|family 6 model 78 stepping 3|1
GPU|||
Crash|SIGSEGV|0x0|0
0|0|libxul.so|mozilla::dom::Promise::CreateFromExisting|hg:hg.mozilla.org/mozilla-central:dom/promise/Promise.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|449|0x18
0|1|libxul.so|mozilla::dom::Promise::All|hg:hg.mozilla.org/mozilla-central:dom/promise/Promise.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|172|0x8
0|2|libxul.so|mozilla::dom::FontFaceSet::Load|hg:hg.mozilla.org/mozilla-central:layout/style/FontFaceSet.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|352|0x1c
0|3|libxul.so|mozilla::dom::FontFaceSetBinding::load|s3:gecko-generated-sources:f288385f14f73fcc2b6d5133d63cc27bdf36e5f1f70f1964dd7f2ab16cd273fb9eeed7af5fa1bc0a5f465e90fe97a51747f9151dd157e5a686cefbbdda5ba7ba/dom/bindings/FontFaceSetBinding.cpp:|838|0x29
0|4|libxul.so|mozilla::dom::FontFaceSetBinding::load_promiseWrapper|s3:gecko-generated-sources:f288385f14f73fcc2b6d5133d63cc27bdf36e5f1f70f1964dd7f2ab16cd273fb9eeed7af5fa1bc0a5f465e90fe97a51747f9151dd157e5a686cefbbdda5ba7ba/dom/bindings/FontFaceSetBinding.cpp:|854|0x5
0|5|libxul.so|mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ConvertExceptionsToPromises>|hg:hg.mozilla.org/mozilla-central:dom/bindings/BindingUtils.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|3191|0x9
0|6|libxul.so|js::CallJSNative|hg:hg.mozilla.org/mozilla-central:js/src/vm/JSContext-inl.h:f6c3a0a19d82db25750d8badccd5cf37e79d028e|290|0x6
0|7|libxul.so|js::InternalCallOrConstruct|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|467|0xf
0|8|libxul.so|InternalCall|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|516|0xd
0|9|libxul.so|js::Call|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|535|0x5
0|10|libxul.so|js::ForwardingProxyHandler::call|hg:hg.mozilla.org/mozilla-central:js/src/proxy/Wrapper.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|176|0x9
0|11|libxul.so|js::CrossCompartmentWrapper::call|hg:hg.mozilla.org/mozilla-central:js/src/proxy/CrossCompartmentWrapper.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|358|0x13
0|12|libxul.so|js::Proxy::call|hg:hg.mozilla.org/mozilla-central:js/src/proxy/Proxy.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|510|0x15
0|13|libxul.so|js::proxy_Call|hg:hg.mozilla.org/mozilla-central:js/src/proxy/Proxy.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|769|0x9
0|14|libxul.so|js::CallJSNative|hg:hg.mozilla.org/mozilla-central:js/src/vm/JSContext-inl.h:f6c3a0a19d82db25750d8badccd5cf37e79d028e|290|0x6
0|15|libxul.so|js::InternalCallOrConstruct|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|449|0x12
0|16|libxul.so|InternalCall|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|516|0xd
0|17|libxul.so|Interpret|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|522|0xf
0|18|libxul.so|js::RunScript|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|417|0xb
0|19|libxul.so|js::InternalCallOrConstruct|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|489|0xf
0|20|libxul.so|InternalCall|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|516|0xd
0|21|libxul.so|js::Call|hg:hg.mozilla.org/mozilla-central:js/src/vm/Interpreter.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|535|0x5
0|22|libxul.so|JS::Call|hg:hg.mozilla.org/mozilla-central:js/src/jsapi.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|3003|0x20
0|23|libxul.so|mozilla::dom::EventListener::HandleEvent|s3:gecko-generated-sources:ccbadb8791154c00d5d9f3f34300a418cdfa4b3b0b60424e60394883162a95118b3edbfce81cbc7a5b48193d5a2618fc449143e250bd5c61dd1340709a3af189/dom/bindings/EventListenerBinding.cpp:|51|0x5
0|24|libxul.so|mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>|s3:gecko-generated-sources:0502cca494d7ae0441ada14535523caade9340fdd09934cf6d31cc421267c319ae3d6f5b43b2730d0b36ae1c87480f3b426c5fa4fec57d51047d83a51acde602/dist/include/mozilla/dom/EventListenerBinding.h:|66|0x1c
0|25|libxul.so|mozilla::EventListenerManager::HandleEventSubType|hg:hg.mozilla.org/mozilla-central:dom/events/EventListenerManager.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1120|0x36
0|26|libxul.so|mozilla::EventListenerManager::HandleEventInternal|hg:hg.mozilla.org/mozilla-central:dom/events/EventListenerManager.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1292|0x19
0|27|libxul.so|mozilla::EventTargetChainItem::HandleEvent|hg:hg.mozilla.org/mozilla-central:dom/events/EventListenerManager.h:f6c3a0a19d82db25750d8badccd5cf37e79d028e|378|0xa
0|28|libxul.so|mozilla::EventTargetChainItem::HandleEventTargetChain|hg:hg.mozilla.org/mozilla-central:dom/events/EventDispatcher.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|527|0xf
0|29|libxul.so|mozilla::EventDispatcher::Dispatch|hg:hg.mozilla.org/mozilla-central:dom/events/EventDispatcher.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|934|0xb
0|30|libxul.so|nsGlobalWindowInner::PostHandleEvent|hg:hg.mozilla.org/mozilla-central:dom/base/nsGlobalWindowInner.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|2109|0x5
0|31|libxul.so|mozilla::EventTargetChainItem::HandleEventTargetChain|hg:hg.mozilla.org/mozilla-central:dom/events/EventDispatcher.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|530|0xb
0|32|libxul.so|mozilla::EventTargetChainItem::HandleEventTargetChain|hg:hg.mozilla.org/mozilla-central:dom/events/EventDispatcher.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|593|0x5
0|33|libxul.so|mozilla::EventDispatcher::Dispatch|hg:hg.mozilla.org/mozilla-central:dom/events/EventDispatcher.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|934|0xb
0|34|libxul.so|nsDocumentViewer::LoadComplete|hg:hg.mozilla.org/mozilla-central:layout/base/nsDocumentViewer.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1066|0x25
0|35|libxul.so|nsDocShell::EndPageLoad|hg:hg.mozilla.org/mozilla-central:docshell/base/nsDocShell.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|7285|0x11
0|36|libxul.so|nsDocShell::OnStateChange|hg:hg.mozilla.org/mozilla-central:docshell/base/nsDocShell.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|7078|0x18
0|37|libxul.so|nsDocLoader::DoFireOnStateChange|hg:hg.mozilla.org/mozilla-central:uriloader/base/nsDocLoader.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1315|0x2b
0|38|libxul.so|nsDocLoader::doStopDocumentLoad|hg:hg.mozilla.org/mozilla-central:uriloader/base/nsDocLoader.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|858|0x22
0|39|libxul.so|nsDocLoader::DocLoaderIsEmpty|hg:hg.mozilla.org/mozilla-central:uriloader/base/nsDocLoader.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|747|0xf
0|40|libxul.so|nsDocLoader::OnStopRequest|hg:hg.mozilla.org/mozilla-central:uriloader/base/nsDocLoader.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|632|0x16
0|41|libxul.so|mozilla::net::nsLoadGroup::RemoveRequest|hg:hg.mozilla.org/mozilla-central:netwerk/base/nsLoadGroup.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|629|0x1f
0|42|libxul.so|nsIDocument::DoUnblockOnload|hg:hg.mozilla.org/mozilla-central:dom/base/nsDocument.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|8409|0x20
0|43|libxul.so|nsDocument::UnblockOnload|hg:hg.mozilla.org/mozilla-central:dom/base/nsDocument.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|8331|0x8
0|44|libxul.so|nsIDocument::DispatchContentLoadedEvents|hg:hg.mozilla.org/mozilla-central:dom/base/nsDocument.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|5314|0x11
0|45|libxul.so|mozilla::detail::RunnableMethodImpl<nsIDocument*, void (nsIDocument::*)(), true, (mozilla::RunnableKind)0u>::Run|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.h:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1164|0x13
0|46|libxul.so|mozilla::SchedulerGroup::Runnable::Run|hg:hg.mozilla.org/mozilla-central:xpcom/threads/SchedulerGroup.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|337|0x15
0|47|libxul.so|nsThread::ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|1096|0x15
0|48|libxul.so|NS_ProcessNextEvent|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|519|0x11
0|49|libxul.so|mozilla::ipc::MessagePump::Run|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|97|0xa
0|50|libxul.so|MessageLoop::RunInternal|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:f6c3a0a19d82db25750d8badccd5cf37e79d028e|326|0x17
0|51|libxul.so|MessageLoop::Run|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:f6c3a0a19d82db25750d8badccd5cf37e79d028e|319|0x8
0|52|libxul.so|nsBaseAppShell::Run|hg:hg.mozilla.org/mozilla-central:widget/nsBaseAppShell.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|157|0xd
0|53|libxul.so|XRE_RunAppShell|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsEmbedFunctions.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|893|0x11
0|54|libxul.so|mozilla::ipc::MessagePumpForChildProcess::Run|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|269|0x5
0|55|libxul.so|MessageLoop::RunInternal|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:f6c3a0a19d82db25750d8badccd5cf37e79d028e|326|0x17
0|56|libxul.so|MessageLoop::Run|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:f6c3a0a19d82db25750d8badccd5cf37e79d028e|319|0x8
0|57|libxul.so|XRE_InitChildProcess|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsEmbedFunctions.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|719|0x8
0|58|firefox|content_process_main|hg:hg.mozilla.org/mozilla-central:ipc/contentproc/plugin-container.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|50|0x14
0|59|firefox|main|hg:hg.mozilla.org/mozilla-central:browser/app/nsBrowserApp.cpp:f6c3a0a19d82db25750d8badccd5cf37e79d028e|280|0x11
0|60|libc-2.23.so||||0x20830
0|61|firefox|MOZ_ReportAssertionFailure|hg:hg.mozilla.org/mozilla-central:mfbt/Assertions.h:f6c3a0a19d82db25750d8badccd5cf37e79d028e|164|0x5
Compartment mismatches are usually either UAFs or a risk of privilege escalation.
Group: core-security → dom-core-security
Boris, this looks like a compartment mismatch inside a function called by FontFaceSetBinding. Could you take a look? Thanks. IIUC, setting up compartments is usually the responsibility of the bindings code.
Flags: needinfo?(bzbarsky)
Hmm.   Promise::All uses aGlobal for the JSContext and the nsIGlobalObject.  In general, those need not be same-compartment, so doing that is really not right.

OK, but why are they not same-compartment in this case?  That's because when we land inside FontFaceSet::Load aCx's compartment is not the compartment of GetParentObject().  And _that_ happens (even though we got the 'load' method off the object itself) because the object's GetParentObject() got changed during the implicit open() that writeln() triggers by the rebinding code added in bug 1450266.

But that's a sideshow.  Here's a testcase that shows the same problem before bug 1450266:

  <iframe></iframe>
  <script>
    var doc = frames[0].document;
    var fonts = doc.fonts;
    document.fonts.load.call(fonts, "large \\");
  </script> 

In this case we're explicitly invoking a function in the compartment of the parent doc on a FontFaceSet from the child doc, whose GetParentObject() is the iframe window.

OK, so the first obvious question is: what global should be used there to create the return Promise?  Behavior I see in other browsers:

* Chrome: Promise is created in the global of "doc"
* Safari: Promise is created in the global of "document"
* Firefox: Promise is created in the global of "document"
* Edge: Doesn't seem to implement document.fonts.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=832273 on this, but maybe it's Firefox and Safari that should change behavior here?  jdaggett is not active anymore, and I don't really want to cc tabatkins here... Maybe he'll respond on the Chromium bug.

But assuming we want to keep our behavior, we just need to make sure that we create this thing in the current global in a consistent way.
Ben, looks like Cache::AddAll uses this API too.  What behavior does it want for the returned promise in the case when the current global doesn't match the Cache object global?
Flags: needinfo?(bzbarsky) → needinfo?(bkelly)
I would guess the Cache object's owning global.  So I think that is the frame's "doc" here.
Flags: needinfo?(bkelly)
OK.  That is _not_ what we do right now, right?  Does the spec cover that case?
Flags: needinfo?(bkelly)
Alright.  So I'm going to do two things:

1) Post a fix for this bug which just preserves the current behavior.
2) File a followup to consider changing behavior.
MozReview-Commit-ID: UO4wssYHj7
Attachment #8967531 - Flags: review?(peterv)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8967531 [details] [diff] [review]
Make it harder to mess up Promise::All

[Security approval request comment]
How easily could an exploit be constructed based on the patch?  Not easily.  I can't think of a way to do it.  We're ending up in a slightly odd state, but not obviously an insecure one.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?  No.  Though mostly because I didn't add tests, which I would like to do in the followup.

Which older supported branches are affected by this flaw?  All of them.

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?  This patch applies as-is to beta.  I have a backport to ESR52 that I'm compiling right now; I will post it once I verify it compiles.

How likely is this patch to cause regressions; how much testing does it need?  I don't believe this patch is very risky.  It creates the promises in the same global as now, so might not even really be observable in non-debug builds.
Attachment #8967531 - Flags: sec-approval?
Comment on attachment 8967531 [details] [diff] [review]
Make it harder to mess up Promise::All

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: _Probably_ none, but we're not 100% sure.  It will
   prevent us from fixing some of our spec bugs, or even getting them filed,
   though....
Fix Landed on Version: 61.
Risk to taking this patch (and alternatives if risky): I think it's pretty low
   risk.  The other option is to not take it.
String or UUID changes made by this patch: None.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/Bug causing the regression]: This is a longstanding issue.
[User impact if declined]: See above.
[Is this code covered by automated tests?]:  No, because that would be a
   testcase for this bug...
[Has the fix been verified in Nightly?]: I tested it locally.
[Needs manual test from QE? If yes, steps to reproduce]: Loading the testcase
   (either the original fuzzer one or mine) in a debug build should work fine.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: See above.
[Why is the change risky/not risky?]: See above.
[String changes made/needed]: None.
Attachment #8967531 - Flags: approval-mozilla-esr52?
Attachment #8967531 - Flags: approval-mozilla-beta?
Attached patch esr52 backport — — Splinter Review
Attachment #8967531 - Flags: approval-mozilla-esr52?
Attachment #8967616 - Flags: approval-mozilla-esr52?
Flags: needinfo?(bkelly)
sec-approval+ for trunk. I'll approve for Beta as well. Relman needs to approved ESR52 but we should take it.
Attachment #8967531 - Flags: sec-approval?
Attachment #8967531 - Flags: sec-approval+
Attachment #8967531 - Flags: approval-mozilla-beta?
Attachment #8967531 - Flags: approval-mozilla-beta+
Comment on attachment 8967616 [details] [diff] [review]
esr52 backport

Fixes a sec-high. Approved for ESR 52.8.0.
Attachment #8967616 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
Attachment #8967531 - Flags: review?(peterv) → review+
Comment on attachment 8967531 [details] [diff] [review]
Make it harder to mess up Promise::All

Review of attachment 8967531 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/promise/Promise.h
@@ +110,5 @@
>    {
>      return mGlobal;
>    }
>  
> +  // Do the equivalent of Promise.resolve in the compartment of aGlobal.  The

And sorry for missing this in bug 1243001 :-(.
https://hg.mozilla.org/mozilla-central/rev/438494d2d17b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Group: dom-core-security → core-security-release
I'd like to file a followup to change Promise::All behavior, but the tests we'd need to write for that bug would trigger this assertion.  I don't really think we should make all those bugs security-sensitive... What's a reasonable way to proceed here?

Note that I don't think there's an actual security issue here in opt builds.
Flags: needinfo?(abillings)
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #21)
> I'd like to file a followup to change Promise::All behavior, but the tests
> we'd need to write for that bug would trigger this assertion.  I don't
> really think we should make all those bugs security-sensitive... What's a
> reasonable way to proceed here?
> 
> Note that I don't think there's an actual security issue here in opt builds.

This will be fixed in 60. If the checkin with tests went in a week or two after that, I assume it would be fine. It would look like normal changes in behavior anyway, wouldn't it? It should be fine.
Flags: needinfo?(abillings)
So to be clear, I should hold off on the followups for another month or so?
Flags: needinfo?(abillings)
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #23)
> So to be clear, I should hold off on the followups for another month or so?

For checkins, yes, unless you think you can mask the security implicatations in a large enough body of work that no one would be able to reasonably tease it out amidst all of the other changes.

This is all assuming that there really is a security issue here. I see your note that you don't think there really is in opt builds. If you're *very* confident of that, we should consider re-rating this bug to a lower severity (if any) and that would probably make this discussion moot.
Flags: needinfo?(abillings)
Looks like this only works because both documents are same-origin, so it shouldn't be a security problem if we get the wrong global (if it turns out we're in fact wrong, as opposed to Chrome being wrong). Should be OK to file and land followups if this is not exploitable.
Whiteboard: [adv-main60-]
Whiteboard: [adv-main60-] → [adv-main60-][adv-esr52.8-]
Flags: qe-verify+
Whiteboard: [adv-main60-][adv-esr52.8-] → [adv-main60-][adv-esr52.8-][post-critsmash-triage]
Reproduced the issue on 61.01 Nightly (20180411234445) with the above steps.

Verified as fixed on Nightly 61.0a1 (2018-05-03) and Beta 61.0b2 using Ubuntu 14.04 (64-bit) on fuzzing builds. 
Unable to verify this issue on esr52 since there's no fuzzing build available.
Verified as fixed on ESR52 debug build with DOMFuzz Helper installed on Ubuntu 14.04.
Flags: qe-verify+
Group: core-security-release
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.