New issue
Advanced search Search tips

Issue 814315 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 792538
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Corruption of chrome extensions via web accessible resources

Reported by avi...@arpeely.com, Feb 21 2018

Issue description

VULNERABILITY DETAILS
By accessing specific URLs exposed by chrome extensions via the "web_accessible_resources" property, it is possible to corrupt the chrome extension from any untrusted Javascript context.

Any extension exposing a web accessible resource using a wildcard syntax is susceptible to the crash and corruption when performing a "GET" request (for example using the fetch API) to the root of the directory preceding the wildcard. See "Reproduction Case" for real-world example.

Some of the most popular extensions on the chrome store utilize wildcards for web accessible content and corrupting those extensions via a web page controlled by an attacker poses significant risk to the user (e.g. disabling of various security and content blocking extensions)


VERSION
Chrome Version: 
stable - 64.0.3282.167 (Official Build) (64-bit)
beta - 65 (64-bit) (Unknown specific version)

Operating Systems:
Linux 4.13.0-32-generic #35-Ubuntu (64bit)
Windows 10 (fully updated) (64bit)
MacOS 10.13 ("High Sierra") (64bit)

REPRODUCTION CASE
For example, let's take extension "lgblnfidahcdcjddiepkckcfdhpknnjh" (Fair AdBlocker).
By inspecting its manifest we can see the web accessible content is exposed using the wildcard: "views/web_accessible/*"

Inherently, by being exposed as web accessible, this resource is CORS accessible most contexts.
Triggering a GET request to the parent directory preceding the wildcard will kill and corrupt the extension, preventing it from loading henceforth.

Reproduceable from a chrome console by executing:
fetch("chrome-extension://lgblnfidahcdcjddiepkckcfdhpknnjh/views/web_accessible")

Verified against multiple popular extensions including: Honey, Avast Online Security, Sourcegraph, Fair AdBlocker.

 
Components: Platform>Extensions
Labels: Needs-Feedback OS-Chrome OS-Linux OS-Mac OS-Windows
Can you elaborate on what you mean when you say "kill and corrupt the extension"? Could you add a screenshot of any errors or other misbehavior?

Running this fetch in Chrome 66 on MacOS 10.13 doesn't seem to have any ill-effects.

Comment 2 by avi...@arpeely.com, Feb 21 2018

Attached is an image of the reproduction case aftermath.

By "kill" I mean immediate termination of the background page and removal of the badge from the toolbar. 

"corrupt" refers to terminology used by the extensions page ("This extension may have been corrupted.")

I have not tested a canary build of Chrome for this issue
Project Member

Comment 3 by sheriffbot@chromium.org, Feb 21 2018

Cc: elawrence@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Untriaged (was: Unconfirmed)
Interesting! I've verified the repro in 65.0.3325.73; it sounds like this was fixed between 65 and 66.
Mergedinto: 792538
Status: Duplicate (was: Untriaged)
Chrome has had this problem before, but it was at least partially fixed in 2015 via  Issue 479598 . 

I believe this particular case was fixed by https://chromium.googlesource.com/chromium/src/+/bfc5ba78ca27a45a099bb1fac477822e49dfa266, making this a dupe of  Issue 792538 , the fix for which landed in 66.0.3337.0.


Owner: proberge@chromium.org

Comment 7 by avi...@arpeely.com, Feb 22 2018

I do not have access to the duplicate issue so I'll take your word for it!
Are there plans of back-porting the fix to the 64/65 stable channels?
Wondering about the disclosure timeline and when would be a safe time to make this information public.
RE #7: The fix will be in 66, but it is not slated for backport to other branches. I've added you to the duplicate issue so you can see it.
Project Member

Comment 9 by sheriffbot@chromium.org, May 31 2018

Labels: -Restrict-View-SecurityTeam allpublic
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

Sign in to add a comment