New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

issue 116192

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Security: Swapped out URL must be a unique origin
Project Member Reported by, Mar 16 2012 Back to list
Web pages are able to script the contents of a swapped out RenderView.  (Low impact.)

Chrome Version: 13 through 19
Operating System: All

1) Visit a page that opens a new window and gets a reference to it (e.g., from
2) Navigate the new window to a cross-site page to trigger a process swap.
3) The original page can control the blank contents of the swapped out RenderView, which is currently showing "about:swappedout".

When Chrome does a cross-process navigation (e.g., for navigating between sites or to a WebUI page), it keeps the RenderView in the old renderer process around, in case the user comes back.  Because the tab is being rendered by another process, we navigate the swapped out RenderView to a blank page to prevent it from doing anything.

There are two requirements for this blank page: it must commit synchronously (to avoid races that have bitten us in the past), and it must not be scriptable by other origins.  We're currently using "about:swappedout" as the URL, which does commit synchronously but can unfortunately be scripted by an opener page.

There is currently little impact from this, because it isn't much different from an attacker opening a window to about:blank and scripting it.  It won't grant the attacker access to any other origins or internal state.  Most actions taken in the swapped out RenderView will never be visible to the user, and the page will be replaced if the tab is navigated back to the process.

The one place I noticed a security impact was in WebCore::Document::shouldAllowNavigation.  I've attached a repro case that shows it's possible to navigate a window you shouldn't be allowed to.  (Technically, it doesn't fully work yet, but it will as soon as I land the fix for  issue 116192 .)

1) a.html opens a window named "one" to b1.html.
2) a.html opens a second window named "two" to b2.html.
3) a.html navigates window "one" to a URL that triggers a process-swap (e.g., view-source).
4) Close the a.html tab.
5) Click a link in b2.html that targets window "one".

Here, Document::shouldAllowNavigation should return false because window "one" is swapped out and doesn't share an ancestor with window "two".  Instead, it returns true because "about:swappedout" has an "about" scheme and thus inherited the origin of its opener in Document::SetSecurityOrigin.

Filing this as a security bug because it affects scripting pages that should be off limits, and in case others find a way to cause more damage with it.
478 bytes View Download
578 bytes View Download
13 bytes View Download
Comment 1 by, Mar 16 2012
In terms of fixes, I was hoping to change about:swappedout to a data: URL, since that's a unique origin and can't be scripted by others.  Unfortunately, data: URLs don't commit synchronously, and that leads to races that can cause the back button to spin ( issue 93427 ).

The only URLs that commit synchronously are those for which SchemeRegistry::shouldLoadURLSchemeAsEmptyDocument returns true (including "about").  I suppose it would be possible to introduce a chrome-swappedout:// scheme that is both treated as an empty document and treated as NoAccess / DisplayIsolated (un-scriptable by others).  Would that be reasonable?
Comment 2 by, Mar 16 2012
And even trying to load substitute data would happen asynchronously.  Is it possible to turn off JavaScript for swapped out pages?  If we change the Page->Settings object to disable JavaScript would that prevent other pages from scripting the swapped out page?  Or, does that only prevent the swapped out page from running script?
Comment 3 by, Mar 16 2012
Status: Started
I'm not sure if Settings::setScriptEnabled(false) would prevent others from scripting the page, but I think that still wouldn't fix the problem with Document::setSecurityOrigin.  That's called from Document's constructor and immediately decides to inherit the origin of its opener if the URL is not valid or has an "about" scheme.

That pretty much makes "about:" URLs dead in the water, even though they appear to currently be the only ones that can commit synchronously.

I have a patch in progress to support a swappedout:// scheme if we're open to that idea:
Comment 4 by, Mar 16 2012
Makes sense.  I think your approach of introducing a registerURLSchemeAsEmptyDocument so that you can define other schemes that should load synchronously is a decent idea.  It means that we can leverage existing origin checks for limiting script interaction.

However, do you have to still worry about cases where the attacker might already have a reference to a node in the swapped out DOM?  Do the origin checks run on each DOM access?  Maybe they do in order to support document.domain assignment?
Comment 5 by, Mar 16 2012
That's not a concern if the swapped out page is empty, right?  The attacker might have a reference to the enclosing window, but when we navigate it to "swappedout://" the entire DOM tree inside the window will be replaced.

And of course, the DOM tree of the page being shown to the user is living in a different renderer process, so that's not a concern.
Comment 6 by, Mar 16 2012
I see.  Makes sense.
Comment 7 by, Mar 16 2012
Comment 8 by, Mar 19 2012
Comment 9 by, Mar 19 2012
Blocking: 116192
Project Member Comment 10 by, Mar 21 2012
The following revision refers to this bug:

r127986 | | Wed Mar 21 10:10:26 PDT 2012

Changed paths:

Use a new scheme for swapping out RenderViews.

BUG= 118664 

Review URL:
Comment 11 by, Mar 21 2012
Status: Fixed
Comment 12 by, Mar 21 2012
Note that the fix relied on this WebKit patch:
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Mstone-19
Status: FixUnreleased
Labels: CVE-2011-3087
Project Member Comment 15 by, Oct 13 2012
Blocking: -chromium:116192 chromium:116192
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Status: Fixed
Project Member Comment 17 by, Mar 10 2013
Labels: -Type-Security -Area-Internals -Internals-Core -SecSeverity-Low -SecImpacts-Stable -SecImpacts-Beta -Mstone-19 M-19 Security-Severity-Low Security-Impact-Stable Security-Impact-Beta Cr-Internals Cr-Internals-Core Type-Bug-Security
Project Member Comment 18 by, Mar 13 2013
Labels: Restrict-View-EditIssue
Project Member Comment 19 by, Mar 14 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member Comment 21 by, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 22 by, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 23 by, Mar 21 2013
Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member Comment 24 by, Jun 14 2016
Labels: -security_impact-beta
Project Member Comment 25 by, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member Comment 26 by, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment