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
,
Feb 16 2017
,
Feb 16 2017
,
Feb 16 2017
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.)
,
Feb 24 2017
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.
,
Feb 28 2017
Issue 696200 has been merged into this issue.
,
Feb 28 2017
,
Feb 14 2018
Marking as not a security bug per comment 5 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by raymes@chromium.org
, Feb 16 2017Components: Platform>Extensions UI>Browser>Navigation
Labels: Security_Severity-Low Security_Impact-Stable
Owner: creis@chromium.org
Status: Assigned (was: Unconfirmed)