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
Email to this user bounced
Closed: Jan 2013
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 169632: Security: extensions can silently gain file: host permissions via permissions API

Reported by, Jan 12 2013 Project Member

Issue description

This template is ONLY for reporting security bugs. Please use a different
template for other types of bug reports.

Please see the following link for instructions on filing security bugs:

When you install an extension, there are warnings about host permissions. However, by design there aren't any for file: permissions - these are handled via a checkbox on the extension settings page.

The same goes for the permissions API, however, the API implementation doesn't respect this checkbox value, so silently allows it.

Chrome Version: all (for about a year or so)
Operating System: all

The attached extension demonstrates the bug. On installing, note that it doesn't have any host permission warnings (just "your tabs and browsing history", the tabs API warning). Go to a file: URL and click the browser action. Note no security warning of any kind. Open dev console, note the script running there.
233 bytes View Download
241 bytes View Download
508 bytes View Download

Comment 1 by, Jan 12 2013

(and also note the "allow file access" checkbox on the extension settings page isn't checked)

Comment 2 by, Jan 15 2013

Project Member
The following revision refers to this bug:

r176853 | | 2013-01-15T08:32:32.006855Z

Changed paths:

Check prefs before allowing extension file access in the permissions API.
BUG= 169632 

Review URL:

Comment 3 by, Jan 15 2013

Status: Fixed
Should this be merged anywhere?

Comment 4 by, Jan 15 2013

Labels: -Restrict-View-SecurityTeam -Pri-0 Restrict-View-SecurityNotify Pri-1 Merge-Approved
Mustafa, can you help to gauge the bug severity and then we can decide which branches to merge this on.

Comment 5 by, Jan 15 2013

Labels: SecSeverity-Low
One thing preventing any extension to exploit this is that the optional permission request is only given on user gesture.

Assigning severity low because requires user interaction.

Comment 6 by, Jan 15 2013

It doesn't require user action in this specific case, see the repro steps.

Comment 7 by, Jan 15 2013

Sorry, I should have said "user gesture". chrome.permissions.request requires user gesture, right? It doesn't seem to be possible to request "file:///*" permission directly from background.js without initializing the browser action by clicking.

Comment 8 by, Jan 15 2013

Ah, right. Yeah I was testing it with a browser action. Makes sense.

Comment 9 by, Jan 17 2013

Labels: -Merge-Approved Release-0 Mstone-26
Given that this is a big change and a low severity, maybe we can just let the fix roll into M26?

Comment 10 by, Jan 17 2013

fine with me

Comment 11 by, Mar 10 2013

Project Member
Labels: -Type-Security -Area-Internals -Feature-Extensions -SecSeverity-Low -Mstone-26 Cr-Platform-Extensions M-26 Security-Severity-Low Cr-Internals Type-Bug-Security

Comment 12 by, Mar 21 2013

Project Member
Labels: -Security-Severity-Low Security_Severity-Low

Comment 13 by, Mar 23 2013

Labels: CVE-2013-0924

Comment 14 by, Nov 18 2013

Labels: -Restrict-View-SecurityNotify
Bulk release of old security bug reports.

Comment 15 by, Jun 14 2016

Project Member
Labels: -release-0
This bug is a regression and does not impact stable. Removing incorrectly added Release- labels.

For more details visit - Your friendly Sheriffbot

Comment 16 by, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 17 by, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 18 by, Oct 2 2016

Labels: allpublic

Comment 19 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment