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

Issue metadata

Status: Fixed
Merged: issue 576867
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security
Nag



Sign in to add a comment
link

Issue 589237: Security: HTTP 302 can navigate to non-web-accessible chrome-extension:// URIs

Reported by qll4m...@gmail.com, Feb 23 2016

Issue description

VULNERABILITY DETAILS
While any direct means of navigating to a chrome-extension-URI fails if it is not web-accessible, a HTTP 302 redirect bypasses this restriction. 
Thus, an attacker is able to load arbitrary extension resources into a new tab by using window.open and pointing it at a redirection (iframes still refuse to load).

There are three attack scenarios:

1. CSRF: An extension can be forced to execute an action just by opening one of its files. This kind of CSRF vulnerability has been demonstrated to work against some extensions in the past [1].

2. Clickjacking: An extension page loaded in to a tab can be controlled by the opener. Either it is loaded in to the background and switched to in the right moment or the opener navigates to a controlled page and uses the history [2] to bait a user into clicking an unwanted action (e.g. disable button on an adblocker).

3. Fingerprinting: I'm only aware of techniques fingerprinting extensions which have web_accessible_resources. I have created a proof of concept able to perform this attack on all extensions, regardless of their settings. It is explained in the REPRODUCTION CASE part. 


[1] http://blog.kotowicz.net/2012/03/chrome-addons-hacking-bye-bye-adblock.html
[2] http://lcamtuf.coredump.cx/clickit/


VERSION
While extremely unlikely to be OS-dependent, the bug was confirmed by me in:
- Chrome 48.0.2564.116 m on Windows
- Chrome 50.0.2657.0 canary (64-bit) on Windows
- Chromium 47.0.2526.106 (64-bit) on Linux


REPRODUCTION CASE
The issue is not easily reproducible by a local HTML file since it relies on a HTTP 302 redirect and a proper origin. Thus, I have created a proof of concept at this URL, which attempts to find out if you use HTTPS Everywhere:

https://c.iceqll.eu/poc/redirect-to-chrome-extension/fingerprint.html

It works like this:

1. Take an extension id and create an URL by prepending chrome-extension:// and appending /manifest.json. A manifest should be available in every extension.

2. window.open a file which redirects to the previously created URL.

3. Wait for one second (so that the redirect finishes) and set the location of the newly opened tab to any file on the same origin (the poc uses its own URL).

4. Wait for one second (so that the same-origin URL finishes to load) and attempt to access the tab's document object.

The extremely interesting behaviour and possible second bug occurs only if the extension exists: In step 4, the document object cannot be accessed due to a security error, even though the page should be same-origin. If the extension does not exist, the object is accessible of course.
 

Comment 1 by och...@chromium.org, Feb 23 2016

Components: Platform>Extensions
Labels: M-49 Security_Severity-Medium Security_Impact-Stable
Owner: mea...@chromium.org
Status: Assigned (was: Unconfirmed)
meacer, mind helping triaging/finding an owner for this?

Comment 2 by qll4m...@gmail.com, Mar 3 2016

I would actually like to speak about this issue amongst others in a wrap-up talk about my master's thesis very soon (April). The meeting will be public (although probably not recorded). Since there is a chance that this will be unfixed at that point, are there any concerns from Google's side or am I good to go?

Comment 3 by mea...@chromium.org, Mar 3 2016

Cc: mea...@chromium.org
Owner: asargent@chromium.org
qll4mail: Sorry, looks like I've completely missed this bug (bug tracker migration confused my filters). Can confirm the POC works on a recent build.

Antony, this looks very similar to  bug 576867  but with a 302 redirect. Could you please take a look? Thanks.

Comment 4 by qll4m...@gmail.com, Mar 5 2016

No worries. Actually, there are other circumstances which allow navigating to chrome-extension URLs. Maybe some of them are described in the bug you mentioned, but since I am not able to read it I will simply list the ones I have found in addition to the redirect:

- window.open from file:///-URIs
- Right-clicking a Link pointing at a chrome-extension://-URL and selecting either "Open in new tab" or "Open in new window". However, Ctrl+Click or Ctrl+Shift+Click does not work.

Comment 5 by qll4m...@gmail.com, Mar 6 2016

And another one:

- Dragging a chrome-extension:// hyperlink to the location bar works.
- Similarly, dragging such a link from text or an input box also works. This seems to be an other trigger, however, since with the above technique file:///-URIs do not work, whereas with this one they do.

I think I will stop now, as I'm not sure if that's even helpful for resolving this specific issue. An attacker would probably have to do some serious convincing to get a user to drag a link in to the location bar.

Comment 6 by ClusterFuzz, Mar 10 2016

Project Member
Labels: Pri-1

Comment 7 by ClusterFuzz, Mar 25 2016

Project Member
Labels: Nag
asargent@: Uh oh! This issue is still open and hasn't been updated in the last 21 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 8 by sheriffbot@chromium.org, Apr 14 2016

Project Member
Labels: -M-49 M-50

Comment 9 by ClusterFuzz, Apr 15 2016

Project Member
asargent@: Uh oh! This issue is still open and hasn't been updated in the last 42 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 10 by sheriffbot@chromium.org, Apr 21 2016

Project Member
asargent: Uh oh! This issue still open and hasn't been updated in the last 57 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Comment 11 by qll4m...@gmail.com, May 4 2016

Just a quick notice on the "restricted" part of this bug: I was recently asked to give a presentation at a local conference on short notice and talked about this bug amongst others. The talk was recorded and, thus, knowledge about the bug has to be considered public now. Sorry.

Furthermore, the bug is also described in my thesis which was made public yesterday (http://nicolas.golubovic.net/thesis/master.pdf). I must admit that when releasing it, I totally forgot about asking here beforehand.

Comment 12 by sheriffbot@chromium.org, May 6 2016

Project Member
asargent: Uh oh! This issue still open and hasn't been updated in the last 72 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Comment 13 by mea...@chromium.org, May 6 2016

Cc: timwillis@chromium.org
qll4mail: Thanks for the heads up. Adding timwillis@ who runs the VRP re comment #11.

Comment 14 by timwillis@google.com, May 6 2016

Labels: reward-topanel
Thanks for reporting this bug - can you provide some more details on when and where you presented this bug?

Don't worry - you're not in trouble and I appreciate your honesty! We usually don't pay for bugs that are disclosed prior to being fixed as noted on https://www.google.com/about/appsecurity/chrome-rewards/:

"Bugs disclosed publicly or to a third-party for purposes other than fixing the bug will typically not qualify for a reward"

... that said, to give you every chance of possibly paying out for this, it's helpful to know when and how you disclosed it.

I've added the label to take this bug to the reward panel for discussion.

Grateful if you could provide the date of your local presentation and whether or not your slides were shared / handed out as well.

Comment 15 by qll4m...@gmail.com, May 6 2016

https://www.xing-events.com/ruhrsec.html << here

I shared my slides, too, and I'm pretty sure I'm not elegible for a bounty anymore but that's not a huge problem for me :-)

Comment 17 by sheriffbot@chromium.org, May 26 2016

Project Member
Labels: -M-50 M-51

Comment 18 by parisa@chromium.org, May 26 2016

Since I synced with asargent@ off thread, here's the status update: asargent@ is working on this as part of a broad fix for several other closely related bugs that all share similar symptoms and roughly the same root. Progress continues...

Comment 19 by asargent@chromium.org, Jun 3 2016

Status: Fixed (was: Assigned)
Ok, I just confirmed that the fix that landed for  bug 576867  (https://codereview.chromium.org/2026163002) also fixes this one.

Comment 20 by ClusterFuzz, Jun 4 2016

Project Member
Labels: Merge-Triage M-52
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Request-XX label, where XX is the Chrome milestone.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz

Comment 21 by sheriffbot@chromium.org, Jun 4 2016

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

Comment 22 by sheriffbot@chromium.org, Jun 14 2016

Project Member
Labels: Merge-Request-M52

Comment 23 by tin...@google.com, Jun 14 2016

Labels: Merge-Review Hotlist-Merge-Review
[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 24 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 25 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 26 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 27 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 28 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 29 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 30 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 31 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 32 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 33 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 34 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 35 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 36 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 37 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 38 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 39 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 40 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 41 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 42 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 43 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 44 by tin...@google.com, Jun 14 2016

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Comment 45 by tin...@google.com, Jun 14 2016

Labels: -Merge-Request-M52 Merge-Request-52
Fixing the label to Merge-Request-52 so that it can be recognized by the merge approval script.
Pls use the right merge request label for future merge requests. Thanks.

Comment 46 by tin...@google.com, Jun 15 2016

Labels: -Merge-Request-52 Merge-Approved-52 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M52 (branch: 2743)

Comment 47 by asargent@chromium.org, Jun 15 2016

Labels: -M-52 -Merge-Review -Merge-Triage -Hotlist-Merge-Approved -Hotlist-Merge-review -M-51 -Merge-Approved-52
Status: Archived (was: Fixed)
Removing a bunch of milestone and merge related labels, and setting status to Archived to try and avoid further bot spam. =)

Comment 48 by ClusterFuzz, Jun 16 2016

Project Member
Status: Assigned (was: Archived)

Comment 49 by est...@chromium.org, Jun 16 2016

Labels: M-52
Hi, security sheriff here. Was this merged to M52? Can it be marked as Fixed now?

Comment 50 by asargent@chromium.org, Jun 16 2016

Mergedinto: 576867
Status: Duplicate (was: Assigned)
Ok, clearly my attempt at evading bots was in vain. =)

I'm now giving up and just marking this as a duplicate of  bug 576867  event though this is really a separate issue that happens to be fixed by the fix for  bug 576867 .

Comment 51 by est...@chromium.org, Jun 16 2016

Labels: -M-52 M-53
Status: Fixed (was: Duplicate)
I'm not a bot. :) I don't think this should be marked as a duplicate if it's not really a duplicate, as that wouldn't be fair to the reporter when and if this goes to the reward panel.

Sounds like there is no plan to merge the fix back to M52 so I'm marking as M53 and Fixed.

Comment 52 by asargent@chromium.org, Jun 16 2016

estark : sorry, not trying to call you a bot :)  - I was referring to comment 48 above by clusterfuzz, where it changed the Status from Archived back to Assigned, which is what I was assuming made it show up for whatever sheriff triage query you use.

Comment 53 by awhalley@chromium.org, Jul 6 2016

Cc: -timwillis@chromium.org
Labels: -reward-topanel reward-0
Yep, no reward for this one since it's been disclosed.

Comment 54 by qll4m...@gmail.com, Jul 6 2016

That's fine. Thanks for fixing :-)

Comment 55 by awhalley@chromium.org, Aug 10 2016

Labels: Release-0-M53

Comment 56 by awhalley@chromium.org, Sep 14 2016

Labels: CVE-2016-5162

Comment 57 by sheriffbot@chromium.org, Sep 23 2016

Project Member
Labels: -Restrict-View-SecurityNotify
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

Comment 58 by sheriffbot@chromium.org, Oct 1 2016

Project Member
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

Comment 59 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 60 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment