Issue metadata
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.
,
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
,
Feb 21 2018
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
,
Feb 21 2018
Interesting! I've verified the repro in 65.0.3325.73; it sounds like this was fixed between 65 and 66.
,
Feb 21 2018
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.
,
Feb 21 2018
,
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.
,
Feb 27 2018
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.
,
May 31 2018
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 |
|||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Feb 21 2018Labels: Needs-Feedback OS-Chrome OS-Linux OS-Mac OS-Windows