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: Fixed
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 598265: Security: Bypassing web_accessible_resources protections

Reported by, Mar 28 2016

Issue description


If a web page tries to open a Chrome extension file, without have been authorized, Chrome will throw a security error exception:

Denying load of chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo/RestClient.html. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

But there is some ways to bypass this protection.


Chrome Version: 49.0.2623.87 (64-bit) (stable)
Operating System: OS X 10.8.5


Open the HTML attached and see the different actions.
Some actions will throw the expected security error exception, others will not.

Chrome extension used in the tests:
1.4 KB View Download

Comment 1 by, Mar 28 2016

Components: Platform>Extensions
Labels: OS-All
Status: Assigned (was: Unconfirmed)
meacer can you take a look at this potential extensions permission issue?

Comment 2 by, Mar 28 2016

Summary: Security: Bypassing web_accessible_resources protections (was: Security: Bypassing Chrome extensions load protection)
jaumlucas: Thank you for the report. Going over the POC:

Case 1: Chrome treats "open link in new tab" navigations as direct, user initiated navigations. In other words, this should be identical to a user opening a new tab and pasting the URL. web_accessible_resources doesn't block direct navigations, so I believe this is working as intended.

Case 2 (and 3): This looks like a variant of a couple of existing bugs ( bug 576867 ,  bug 589237 ). That said, it doesn't seem possible to leak any information from the iframe, particularly whether it loads or not. I'll let asargent comment on this.

A minimized repro for case 2:

<a id="link" href="chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo/RestClient.html" target="iframe">Link</a>
<iframe src="chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo/RestClient.html" name="iframe" id="iframe"></iframe>
document.onclick = function() { }; // So that the user doesn't need to click specifically on the link

Case 4, 5: These open the resource in a new window. Like Case 1, I don't think we intend to block these. Can't seem to get any useful data from these cases either.
Case 6, 7: These use form submits. I'm not sure what the expected behavior is here. asargent to the rescue.

Antony, assigning to you, please reassign or close as appropriate.

Comment 3 by, Apr 3 2016

Hello Antony,

Just wanting to make sure you've seen this ticket.  Please feel free to reassign, relabel, or close as appropriate.


Comment 4 by, Apr 5 2016

Status: Started (was: Assigned)
Taking a look today.

Comment 5 by, Apr 5 2016

Labels: Security_Impact-Stable
asargent@: Do you see any information leakage to the web page? If not, then this shouldn't be flagged as a security issue.

Comment 6 by, Apr 7 2016

Friendly ping for the question in #5?

Comment 7 by, Apr 7 2016

Status: WontFix (was: Started)
Ok, I've taken a look and I agree with Mustafa that I don't see any information leakage here to the attacker script in any of these cases, and extensions code always need to be prepared to handle XSRF kinds of attacks, so I'm marking this as Wontfix. 

To the original reporter: can you demonstrate any attack where the script determines that the extension is installed even if it has no web_accessible_resources? We can reopen this bug if so.

Comment 8 by, Apr 8 2016


Sir, yes sir.
1.4 KB View Download

Comment 9 by, Apr 8 2016

Status: Started (was: WontFix)

Comment 10 by, Apr 8 2016

Labels: Security_Severity-Low Pri-2

Comment 11 by, Apr 11 2016

Ok, I can confirm that the information leak does occur. It doesn't reproduce if you use a file url (eg downloading the html file from comment 8 and loading the page from the filesystem), but does seem to work if you run it from an http(s) page. I went back to an old chrome version (31.0.1635.0) and verified that the bug didn't used to happen - I'm going to try and bisect to find where this started breaking.

Comment 12 by, Apr 13 2016

The bisect shows that this broke a while back - here's the relevant output:

You are probably looking for a change made after 287191 (known good), but no later than 287209 (first known bad).


I looked at the set of changes in that changelog, and then did a local build using source around that time, and have verified that the change which seems to have broken this was: 
(855d7d572fb4d4aaf97464771661c6805e0347a5 rev 287192)

+cc creis, nasko

nasko - this is the bug I mentioned in our recent chat. I'll be working on creating a browser test for this as well as the semi-related  bug 598265 .

Comment 13 by, Apr 15 2016

If this is caused by the navigation transitions CL and this experiment was cancelled, can we just revert the changes?

Comment 14 by, Apr 15 2016

Seems reasonable to me - looking at  bug 370696 , it looks like a bunch of other pieces of the feature have been getting removed. 

I'm not all that familiar with this area of code - nasko, are you able to take this on? If not I can spend some more time to get up to speed on how things work.

Comment 15 by, Apr 19 2016

BTW, here's the test I wrote a few days ago that demonstrates this problem:

Comment 16 by, Apr 20 2016

I've been poking at this and there are two pieces involved:

1. We have a difference in behavior depending whether an extension is installed or not. This allows other side effects to be used to determine if an extension is present or not. ChromeExtensionsRendererClient::ShouldFork behaves differently in - when an extension is installed and navigated to from a regular web process, the return value from ShouldFork is true and we end up sending the navigation to be performed by the browser process. If there is no such extension installed, normal resource request is made, which fails with ERR_FAILED.

2. On the browser side, ChromeContentBrowserClientExtensionsPart::ShouldAllowOpenURL allows the navigation to continue if an extension is not installed or enabled. Is there a reason for allowing this to proceed? I need to think through whether this can be abused for information leakage or not.
Furthermore, when ShoulAllowOpenURL returns false, meaning that the navigation should not be performed, the code in NavigatorImpl::RequestOpenURL (which calls it) rewrites the URL to "about:blank". The changes in made is such that a browser-side navigation to "about:blank" is treated as same-site navigation. This is in general the correct behavior, as navigating any frame to "about:blank" should put the new document in the origin of the document that initiated the navigation - in this case the attacker's page.

The combination of 1 and 2 leads to the information leakage, as for existing extension, we would send the navigation to the browser process, which will fail the ShouldAllowOpenURL and navigate it to about:blank. This allows the script to use origin checks to deduce whether the extension is installed or not.

To eliminate the info leak, we need to ensure we have consistent behavior regardless of whether an extension is installed or not. 
asargent@, why do we have a difference in behavior in ShouldFork? If we make it to only return true when we know the URL we want to navigate to is web_accessible_resource, I think we should be fine, since it will keep the navigation in the renderer and it will result in a ERR_FAILED regardless. Also, in the case of the URL being web_accessible_resource, we know on the browser side we will allow the navigation to succeed.

Comment 17 by, May 21 2016


Do you have an update about this one?


João Lucas Melo Brasio.

Comment 18 by, Jun 8 2016

Quick update - there have been some similar bug reports around web_accessible_resources and a fix landed for one of them, but I just checked and that doesn't fix this one. There are one or two other higher priority security bugs I'm looking at; then I'll be circling back to this one.

Comment 19 by, Jun 17 2016


Thanks for the feedback.

Comment 20 by, Aug 15 2016


Do you have an update about this one?

Comment 21 by, Aug 17 2016

Labels: -OS-All
I'm now circling back to have a look.

Comment 22 by, Aug 19 2016

Ok. Thanks.

Comment 23 by, Aug 19 2016

Labels: OS-Mac

Comment 24 by, Sep 16 2016


Do you have an update about this bug?

Comment 25 by, Sep 28 2016


Do you have an update about this bug?

Comment 26 by, Sep 28 2016

I've been looking into some approaches for a fix - one that seems promising is checking web_accessible_resources in the ShouldFork method, returning false if the URL isn't listed. But that currently breaks two extensions tests:


The WindowOpenNoPrivileges essentially does the following: open the NTP, and call to open some chrome-extension:// url. In conversation with Devlin and Nasko it sounds like in an ideal world we'd actually want to disallow such navigations if the url in question isn't listed in web_accessible_resources, but I need to look more into the history of that test and possibly gather some more data about how widely used this is to make sure we wouldn't cause a lot of breakage. I also need to look more into why the LinkToWebAccessibleResources test fails.

Comment 27 by, Sep 28 2016

Quick update:

-The ExtensionResourceRequestPolicyTest.LinkToWebAccessibleResources failure I had observed was likely a flake, since I haven't been able to reproduce it. 

-The ExtensionBrowserTest.WindowOpenNoPrivileges test was added a long time ago in r25329 (, before we even had the concept of web_accessible_resources (which was added in r115401 

So we likely can just adjust the WindowOpenNoPrivileges test to make the resource being opened web_accessible. That still leaves open the question of how many existing uses of<non-web-accessible-url>) we might break. I'm going to look into getting some data on that.

Comment 28 by, Jan 12 2017

Any news?

Comment 29 Deleted

Comment 30 Deleted

Comment 31 by, May 4 2017

Can I disclose the bug?

Comment 32 by, May 4 2017

I'm no longer working on chrome, reassigning to Devlin for triage.

Comment 33 by, Jun 28 2017


Comment 34 by, Jun 28 2017

This bug clearly slipped through the cracks.  I'll see if I can reprioritize.  That said, you have patiently waited for a *long* time, so I think you should be allowed to disclose this - but please wait for confirmation from nasko@ or creis@.

nasko@, creis@, what do you think?

Comment 35 by, Jun 28 2017

Thanks, Devlin.

Is this issue valid for the bug bounty program?

Comment 36 by, Jun 28 2017

We have been given more than enough time to act on this bug. It is unfortunate it did slip through, but that should not impact the decision to disclose or not. 

As to the rules of the VRP program, I'm not certain, so adding awhalley@ to help answer whether disclosure of the bug will disqualify it.

Comment 37 by, Jun 29 2017



Comment 38 by, Jun 29 2017

Components: UI>Browser>Navigation
+alexmos@ and nick@, who have looked at some web accessible resources issues as well and may have thoughts on how to fix.

Comment 39 by, Jul 27 2017


Do you have any update?

Comment 40 by, Aug 4 2017


Can you guys submit this bug to the VRP panel since I waited for a long time?


Comment 41 by, Aug 7 2017

Hello! I'm afraid that we only consider bugs for reward once they have been fixed. Also, fair warning that we tend not to reward low severity bugs often, but I'll make sure this goes in front of the panel when it is fixed and ensure there's a second look at the severity rating.

Comment 42 by, Aug 9 2017

Labels: -Pri-2 Pri-1
@awhalley Even when it's us that's clearly dropped the ball?  In this particular case, the reporter filed the bug >1 year ago, and it's been unaddressed to a combination of lower priority, other P0s, and shifting people - but it's unfortunate that the holes in our process cause more issues...

@jaumlucas, sincerest apologies on this.  I'm bumping priority on this and going to try to push a fix this week so that we can get this through to panel.  Sorry again for all the (extremely!) long delays, and thanks so much for your patience.

Comment 43 by, Aug 9 2017


I appreciate the increase in the priority but don't worry.

Since 2011 I have sent hundreds of security bugs to Google (Web, Android, Chrome, Apps, etc.), and you guys are awesome every time, I have no complaints at all.

I understand that this is a low severity bug and it unintentionally slipped through the cracks. Sometimes it happens.

Many thanks for your consideration and hard work.

Please let me know once this bug is fixed.

Comment 44 by, Aug 9 2017

jaumlucas@ - thanks for your understanding!

Comment 45 by, Aug 19 2017

Project Member
The following revision refers to this bug:

commit f1afce25b3f94d8bddec69b08ffbc29b989ad844
Author: Devlin Cronin <>
Date: Sat Aug 19 01:21:48 2017

[Extensions] Update navigations across hypothetical extension extents

Update code to treat navigations across hypothetical extension extents
(e.g. for nonexistent extensions) the same as we do for navigations
crossing installed extension extents.

Bug:  598265 

Change-Id: Ibdf2f563ce1fd108ead279077901020a24de732b
Commit-Queue: Devlin <>
Reviewed-by: Alex Moshchuk <>
Reviewed-by: Nasko Oskov <>
Cr-Commit-Position: refs/heads/master@{#495779}

Comment 46 by, Aug 28 2017

Thanks @rdevlin.

Comment 47 by, Aug 28 2017

Status: Fixed (was: Started)
This should be fixed, I think.  Given we're close to stable cut for M61, it's probably not worth merging back, but could be - I'll let some security folks weigh in.

I'm also pretty sure there are going to be other similar situations to this - we have a bunch of different places we check for web accessible resources + installed extensions, etc, so there are probably other edge cases.  We should really coalesce them if we can.

Comment 48 by, Aug 28 2017

Labels: reward-topanel

Comment 49 by, Aug 28 2017

IMHO, this doesn't warrant merge to M61, given we are very close to branch point and the severity is low.

Comment 50 by, Aug 28 2017

Labels: M-62

Comment 51 by, Aug 29 2017

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

Comment 52 by, Sep 1 2017

Labels: -reward-topanel reward-unpaid reward-500
*** 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 53 by, Sep 1 2017

The VRP panel decided to award $500 for this bug.  Many thanks!  Also, when this bug is included in release notes, how would you like to be credited?

Comment 54 by, Sep 1 2017

Hey awhalley@,

Thank you very much.

Credit: João Lucas Melo Brasio (

Comment 55 by, Sep 1 2017

Labels: -reward-unpaid reward-inprocess

Comment 56 by, Sep 8 2017

Issue 746567 has been merged into this issue.

Comment 57 by, Oct 16 2017

Labels: Release-0-M62

Comment 58 by, Oct 18 2017

Labels: CVE-2017-15391

Comment 59 by, Dec 5 2017

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 60 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment