New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 602821 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 601629
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , All
Pri: 1
Type: Bug



Sign in to add a comment

ASSERTION FAILED: !localFrame || (localFrame->isLocalFrame()) when frames are nonlocal but same-origin

Project Member Reported by nick@chromium.org, Apr 12 2016

Issue description

Occasionally we can get into cases where two RenderFrames are same origin but in different processes (e.g., if making them same process would require oopifs). We seem to crash and burn in these cases, e.g. if one frame tries to access "window.location.href" of the other:

====================================
Here is what the failure looks like:
====================================

ASSERTION FAILED: !localFrame || (localFrame->isLocalFrame())
Backtrace:
        blink::toLocalFrame [0x18D1ADDD+77] (c:\src\cr\src\third_party\webkit\source\core\frame\localframe.h:309)
        blink::Location::url [0x19931989+41] (c:\src\cr\src\third_party\webkit\source\core\frame\location.cpp:56)
        blink::Location::href [0x19930886+70] (c:\src\cr\src\third_party\webkit\source\core\frame\location.cpp:68)
        blink::LocationV8Internal::hrefAttributeGetter [0x18EEBB9B+75] (c:\src\cr\src\out\debug\gen\blink\bindings\core\v8\v8location.cpp:66)
        blink::LocationV8Internal::hrefAttributeGetterCallback [0x18EEBC2C+12] (c:\src\cr\src\out\debug\gen\blink\bindings\core\v8\v8location.cpp:71)
        v8::internal::PropertyCallbackArguments::Call [0x02B8E0F2+178] (c:\src\cr\src\v8\src\api-arguments.h:128)
        v8::internal::Object::GetPropertyWithAccessor [0x02C1E997+375] (c:\src\cr\src\v8\src\objects.cc:1066)
        v8::internal::Object::GetProperty [0x02C1DF21+305] (c:\src\cr\src\v8\src\objects.cc:738)
        v8::internal::LoadIC::Load [0x02B91CAB+891] (c:\src\cr\src\v8\src\ic\ic.cc:644)
        v8::internal::__RT_impl_Runtime_LoadIC_Miss [0x02B99799+553] (c:\src\cr\src\v8\src\ic\ic.cc:2038)
        v8::internal::Runtime_LoadIC_Miss [0x02B92C5A+90] (c:\src\cr\src\v8\src\ic\ic.cc:2019)
        v8::internal::`anonymous namespace'::Invoke [0x02A4A450+368] (c:\src\cr\src\v8\src\execution.cc:97)
        v8::internal::Execution::Call [0x02A49C78+424] (c:\src\cr\src\v8\src\execution.cc:153)
        v8::Script::Run [0x02AE2AD7+567] (c:\src\cr\src\v8\src\api.cc:1791)
        blink::V8ScriptRunner::runCompiledScript [0x18EB074B+747] (c:\src\cr\src\third_party\webkit\source\bindings\core\v8\v8scriptrunner.cpp:417)
        blink::ScriptController::executeScriptAndReturnValue [0x18E30ACE+718] (c:\src\cr\src\third_party\webkit\source\bindings\core\v8\scriptcontroller.cpp:153)
        blink::ScriptController::evaluateScriptInMainWorld [0x18E306A5+245] (c:\src\cr\src\third_party\webkit\source\bindings\core\v8\scriptcontroller.cpp:411)
        blink::ScriptController::executeScriptInMainWorldAndReturnValue [0x18E316F6+38] (c:\src\cr\src\third_party\webkit\source\bindings\core\v8\scriptcontroller.cpp:392)
        blink::WebLocalFrameImpl::executeScriptAndReturnValue [0x12C5FE27+439] (c:\src\cr\src\third_party\webkit\source\web\weblocalframeimpl.cpp:789)
        content::RenderFrameImpl::OnJavaScriptExecuteRequestForTests [0x0C8E1A90+336] (c:\src\cr\src\content\renderer\render_frame_impl.cc:1828)

====================================
Here is a browsertest that triggers this crash. Site isolation is not required.
====================================

// When two frames are same-origin but cross-process; they should behave as if
// they are not same-origin, and should not crash.
IN_PROC_BROWSER_TEST_F(RenderFrameHostManagerTest,
                       SameOriginFramesInDifferentProcesses) {
  StartEmbeddedServer();

  // Load a page with links that open in a new window.
  NavigateToURL(shell(), embedded_test_server()->GetURL(
                             "a.com", "/click-noreferrer-links.html"));

  // Get the original SiteInstance for later comparison.
  scoped_refptr<SiteInstance> orig_site_instance(
      shell()->web_contents()->GetSiteInstance());
  EXPECT_TRUE(orig_site_instance.get() != NULL);

  // Test clicking a target=foo link.
  ShellAddedObserver new_shell_observer;
  bool success = false;
  EXPECT_TRUE(ExecuteScriptAndExtractBool(
      shell()->web_contents(),
      "window.domAutomationController.send(clickSameSiteTargetedLink());"
      "saveWindowReference();",
      &success));
  EXPECT_TRUE(success);
  Shell* new_shell = new_shell_observer.GetShell();

  // Wait for the navigation in the new tab to finish, if it hasn't.
  WaitForLoadStop(new_shell->web_contents());
  EXPECT_EQ("/navigate_opener.html",
            new_shell->web_contents()->GetLastCommittedURL().path());

  // Clear the opener.
  EXPECT_TRUE(ExecuteScriptAndExtractBool(
      new_shell->web_contents(),
      "window.opener = null;"
      "window.domAutomationController.send(window.opener == null)",
      &success));
  EXPECT_TRUE(success);

  // Do a cross-site navigation that winds up same-site
  NavigateToURL(new_shell, embedded_test_server()->GetURL(
                               "b.com", "/cross-site/a.com/title1.html"));
  EXPECT_NE(shell()->web_contents()->GetSiteInstance(),
            new_shell->web_contents()->GetSiteInstance());

  // Now navigate the new tab to a different site.
  std::string result;
  EXPECT_TRUE(ExecuteScriptAndExtractString(
      shell()->web_contents(),
      "window.domAutomationController.send(getLastOpenedWindowLocation());",
      &result));
  EXPECT_EQ("?", result);
}
 

Comment 1 by nick@chromium.org, Apr 12 2016

It doesn't seem likely that we'll be able to completely avoid these cases. So we should probably make this scenario throw SecurityErrors (as if they were cross-origin) rather than crashing. 

Comment 2 by creis@chromium.org, Apr 12 2016

Labels: Restrict-View-SecurityTeam
This is likely the cause for  issue 601629 , so I'll restrict view on this.

Comment 3 by creis@chromium.org, Apr 12 2016

This shows up in the wild as blink::SecurityOrigin::canAccessCheckSuborigins, such as crash ID fe0f29c400000000.

Comment 4 by creis@chromium.org, Apr 13 2016

Cc: nick@chromium.org esprehn@chromium.org creis@chromium.org
For context, here's why this case is possible (copied from the discussion on https://codereview.chromium.org/1887553002/):

Since Chrome launched, we've made browser-initiated cross-site navigations go cross-process, but renderer-initiated cross-site navigations usually don't.  This was to preserve compatibility in cases that a cross-site iframe opens a popup (e.g., OAuth), etc.  It's explained in the following doc and paper:
https://www.chromium.org/developers/design-documents/process-models
http://www.charlesreis.com/research/publications/eurosys-2009.pdf

As a result, you could have two windows on site A, go cross-process in the second one to site B (by typing in the omnibox), and then click a link in both to site C.  They'll be same-site but different processes.  Yes, this breaks a possible script relationship, but it's unlikely to matter in practice relative to the OAuth case.  (We decided it was a good tradeoff because the user initiated the navigation to B, basically leaving the previous context behind.  You can almost view that as creating a new unit of related browsing contexts / BrowsingInstance.  Maybe we can formalize that concept.)

This wasn't a problem to Blink before RemoteFrames, because the origin of the cross-process window looked like swappedout://.  With RemoteFrames, we replicate the origin and it looks like it should pass the check.

Full --site-per-process mode would eliminate this possibility, but most realistic modes (even those with OOPIFs) still have it.  It's worth noting that TDI actually depends on this ability a bit more to avoid process inversions (where main frames would frequently end up in the subframe process).

Comment 5 by dcheng@chromium.org, Apr 13 2016

Mergedinto: 601629
Status: Duplicate (was: Assigned)
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 23 2016

Labels: -Restrict-View-SecurityTeam
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment