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

Issue 692746 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Security: Right click menu can open chrome-extension:// URLs from websites

Reported by nicolasg...@gmail.com, Feb 15 2017

Issue description

The bug
=======
Right click a chrome-extension:// link and select either

1. "Open in a new tab"
2. "Open in a new window"

It opens the extension page.


What should happen
==================
Note that a Ctrl-Click (equivalent to "Open in a new tab") or Ctrl-Shift-Click (equivalent to "Open in a new window") does _not_ open the extension page. They open about:blank. It would be consistent to do the same with the right click menu.


Why this may be a security bug
==============================
Two attack scenarios come to my mind:

1. Opening an extension page might trigger an unwanted action for a user ("CSRF"-style of attack).
2. It is possible to open extension URLs with XSS payloads.

Let's take the Enhanced History Chrome extension for scenario 2 to show this has some real world impact. Note that the vulnerability described in the next paragraph has been reported to the extension already.

Enhanced History for Chrome suffers from an XSS flaw in it's search functionality. An attack would look like this:

chrome-extension://blpnkmdkoapbdhpmemnaikpbhajknmdb/index.html#search/<b>injection</b>

Opening such an URL from a website is not easily possible - except for the two reported methods above. Thus, it enables a simpler way to trigger XSS bugs in some extensions.

Multiple limiting factors to this kind of attack:
1. Extensions have a default CSP that will mitigate most straightforward attacks. Enabling unsecure-eval, AngularJS in other extensions [1] or scriptless attacks can still pose some limited risk.
2. It might require a fair amount of social engineering to make a user right click and open in a new tab. This might be offset by targeting a large enough number of users.

I am not entirely sure the right click "bypass" is a full blown security bug on its own. Thus, I leave this decision to you.


REPRODUCTION
============
Paste the following link into your address bar:

data:text/html,<a href="chrome-extension://ghbmnnjooekpmoecnnnilnnbdlolhkhi/manifest.json">Click here</a>

It assumes the Google Docs Offline extension is installed and enabled. Right clicking and selecting the menu entries will open the link, Ctrl-Click will not.


VERSION
=======
Tested on Chrome Canary 58.0.3013.0 canary (64-bit)


[1] Section 6.2.2 in https://golubovic.net/thesis/master.pdf
 

Comment 1 by raymes@chromium.org, Feb 16 2017

Cc: nasko@chromium.org mea...@chromium.org
Components: Platform>Extensions UI>Browser>Navigation
Labels: Security_Severity-Low Security_Impact-Stable
Owner: creis@chromium.org
Status: Assigned (was: Unconfirmed)
creis/meacer/nasko: Is it problematic that chrome://extension links can be opened via the context menu? It doesn't seem like an issue to me but there might be more background to this thank I know if.

Comment 2 by raymes@chromium.org, Feb 16 2017

Labels: OS-All
Project Member

Comment 3 by sheriffbot@chromium.org, Feb 16 2017

Labels: Pri-2

Comment 4 by creis@chromium.org, Feb 16 2017

Cc: rdevlin....@chromium.org creis@chromium.org nick@chromium.org
Owner: rdevlin....@chromium.org
Just as another data point, extensions can also have web accessible resources listed in their manifest, and pages are allowed to link to those.  For example, you can install 
https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo and then link to chrome-extension://pnhechapfaindjhompbnflcldabbghjo/html/nassh.html.  That will work whether you click on it, middle click, or use the context menu.

For background, the context menu is generally treated like a browser-initiated navigation (similar to copying and pasting a URL in the address bar), unlike middle clicks.  That explains why it doesn't go through the same set of checks, and why I probably wouldn't consider this a big security issue.  I've never been thrilled with the difference between those actions, though, so maybe it's worth a discussion about changing it.

In the short term, we could maybe do a web accessible resources check on context menu links?  Devlin, does that sound like the right thing to be doing here?  (I'm not sure where those checks live today, but feel free to assign the bug back if you need to.)
Cc: -creis@chromium.org
Owner: creis@chromium.org
I had brought this up to Charlie before, and we had come to the same conclusion around browser-initiated (context menu) vs renderer-initiated (left click, middle click) navigations.

While the difference in behavior is a little odd, I'd say this isn't a security bug.  I'm also not 100% sure what the best behavior here is (because we'd probably still want to allow navigation through e.g. copy-pasting an url, so there will always be some difference between approaches).

Given that, back to Charlie for further thought. :)  I won't have time to get to this soon, unless we decide that it is a security risk (or get a definitive answer on what the best behavior is).

For reference, most of the checks are in either extension_navigation_controller.cc or extension_protocols.cc.

Comment 6 by mea...@chromium.org, Feb 28 2017

Issue 696200 has been merged into this issue.

Comment 7 by mea...@chromium.org, Feb 28 2017

Cc: masatoki...@gmail.com
Adding masatokinugawa@gmail.com who also reported this in bug 696200.

Comment 8 by awhalley@google.com, Feb 14 2018

Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-Stable Type-Bug
Marking as not a security bug per comment 5

Sign in to add a comment