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 4 users

Issue metadata

Status: Verified
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 797525: Security: XSS in "Site blocked" (supervised user) interstitial and chrome://interstitials/supervised_user

Reported by, Dec 24 2017 Project Member

Issue description

The "Site blocked" interstitial for supervised users has multiple XSS vulnerabilities at [1].
The generated HTML is used in two places, and can be used as follows:
- Modify the custodian name and/or e-mail to contain a XSS payload. When the user triggers the supervised user interstitial, XSS will occur.
- Open the chrome://interstitials/supervised_user debug page with additional query string parameters. This can be done manually or with a Chrome extension.

The Content-Security-Policy of interstitial pages is as follows [2]:
script-src chrome://resources 'self' 'unsafe-eval' 'unsafe-inline';
... and because of this very liberal policy, it does not offer protection against XSS (notably 'unsafe-inline' is allowed).

The impact of this vulnerability is access to any privileged webui API that is exposed to the page, as well as the ability to navigate to any other restricted URL ( such as chrome://quit ).

Chrome Version: 63.0.3239.108 (stable), 65.0.3303.0 (canary)

Open the following URL and observe a navigation to chrome://quit:

Or achieve the same effect by loading the attached Chrome extension via "Load unpacked extension" at chrome://extensions (extensions are normally not allowed to navigate to chrome://quit ).

The most realistic scenario to abuse this is through an extension: either by a malicious extension that directly calls chrome.tabs.create with the given URL (as in the attached example), or by an extension that blindly passes external URLs to a chrome.tabs.create/update function (which is not uncommon, sadly).

563 bytes Download

Comment 1 by, Dec 24 2017

Status: Started (was: Unconfirmed)

+cc bauerb for review.

Comment 2 by, Dec 24 2017

Labels: Security_Impact-Stable
Nice find, thanks! 

Is there any reason why the CSP cannot be tightened for all interstitials?

Comment 3 by, Dec 24 2017

Project Member
The following revision refers to this bug:

commit a296eff269063ef8daa7cdacf4483d3993214a1b
Author: Rob Wu <>
Date: Sun Dec 24 15:37:52 2017

Fix XSS in supervised user interstitial

BUG= 797525 

Change-Id: Ib5cfa732b0f4de8645031c0166e4d67633a65c93
Reviewed-by: Bernhard Bauer <>
Commit-Queue: Rob Wu <>
Cr-Commit-Position: refs/heads/master@{#526158}

Comment 4 by, Dec 28 2017

Labels: M-64 Security_Severity-Medium Pri-1
Labeling as medium-severity because this would require the user to install an extension to exploit.

Comment 5 by, Jan 14 2018

Labels: Merge-Request-64
Status: Verified (was: Started)
Verified fixed in 65.0.3322.0 using the STR from the report.

Requesting merge of a296eff269063ef8daa7cdacf4483d3993214a1b to M-64.

Comment 6 by, Jan 14 2018

Project Member
Labels: -Merge-Request-64 Hotlist-Merge-Review Merge-Review-64
This bug requires manual review: We are only 8 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit - Your friendly Sheriffbot

Comment 7 by, Jan 14 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 8 by, Jan 16 2018

Labels: reward-topanel

Comment 9 by, Jan 16 2018

awhalley@ I don't think we have to take this into M64 at this point but letting you make that call :)

Comment 10 by, Jan 16 2018


Comment 11 by, Jan 17 2018

Labels: -Hotlist-Merge-Review -Merge-Review-64 Merge-Rejected-64
awhalley@ also agrees that we can wait to ship this fix in M65.

Comment 12 by, Jan 17 2018

> The impact of this vulnerability is access to any privileged webui API that is exposed to the page, as well as the ability to navigate to any other restricted URL ( such as chrome://quit ).

As far as I can tell chrome://interstitials pages don't have access to privileged APIs. Can you please give an example?

Comment 13 by, Jan 17 2018

> The impact of this vulnerability is access to any privileged webui API that is exposed to the page,
> as well as the ability to navigate to any other restricted URL ( such as chrome://quit ).

As far as I can tell chrome://interstitials pages don't have access to privileged APIs. Can you please give an example?

This XSS impacts two pages, chrome://interstitials (easy to exploit, see PoC) and the actual supervised user error interstitial (I haven't checked the list of available APIs here because the demonstrated issue in chrome://interstitials itself seems enough).
All WebUI pages (including chrome://intersititals) have access to the default webUI APIs from GenericHandler:

You can easily test this with the following snippet (crashes the tab, chrome://kill can normally not be opened by regular pages or extensions - see content::IsRendererDebugURL ):
chrome.send('navigateToUrl', ['chrome://kill', '', 0, false, false, false, false]);

Though webUI pages can seemingly already navigate to such URLs with standard JS APIs such as `location = ...` (as shown by my exploit).

Comment 14 by, Jan 17 2018

Thanks, so navigateToUrl is the only additional API that an XSS will have access to.

I'm not entirely sure that's a security sensitive API though. Best it can do is DoS the browser by navigating to special URLs. Note that an extension can already emulate the behavior of chrome://kill by closing all tabs ( bug 180066 ). Beyond that, an extension doesn't seem to gain much by XSSing these interstitials.

Comment 15 by, Jan 18 2018


chrome://quit's code path is very different from closing Chrome by closing all tabs using extension APIs.
chrome://restart allows extensions to restart Chrome (something that extensions cannot do (see ExtensionTabUtil::IsKillURL ).

I mainly view this vulnerability as a gadget to build automatic exploits for vulnerabilities surrounding the startup/shutdown logic of Chrome.
E.g. in the past I reported a UAF upon shutdown ( bug 518749 ), and in search for a gadget for a fast shutdown, I found and reported  bug 518827 .

Now I don't have a new shutdown/startup vulnerability in mind this time, but I think that it's in the best interest of everyone to already report this vulnerability without waiting for more vulnerabilities to build a full exploit chain.

Comment 16 by, Jan 19 2018

Labels: -M-64 M-65
Merge rejected, so I'm changing the milestone label to 65.

Comment 17 by, Jan 22 2018

Labels: -reward-topanel reward-unpaid reward-1000
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Comment 18 by, Jan 22 2018

The VRP Panel decided to award $1,000 for this report ($500 for the issue and $500 for the patch), as it wasn't clear what privileged webui APIs are actually accessible. They were willing to re-evaluate if you can show what additional privileges an attacker can achieve in this case.

Comment 19 by, Jan 22 2018

Labels: -reward-unpaid reward-inprocess

Comment 20 by, Jan 23 2018

Supervised interstitials are not available from the web, there is an extension installation requirement, and the XSS gives limited privileges to the extension (navigating to chrome:// URLs). Given these, downgrading severity to low per severity guidelines, as this bug doesn't seem to meet medium severity criteria [1]. As awhalley@ said, happy to reevaluate in light of new information (which I think is quite probable).


Comment 21 by, Jan 23 2018

Labels: -Security_Severity-Medium Security_Severity-Low

Comment 22 by, Jan 23 2018

(And to be clear, I don't think this should decrease the reward amount)

Comment 23 by, Mar 6 2018

Labels: Release-0-M65

Comment 24 by, Mar 6 2018

Labels: CVE-2018-6081

Comment 25 by, Apr 22 2018

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

For more details visit - Your friendly Sheriffbot

Comment 26 by, Apr 25 2018

Labels: CVE_description-missing

Comment 27 by, Jul 28 2018

Project Member
Labels: -Pri-1 Pri-2

Comment 28 by, Nov 14

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment