New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 424961 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: Local file access in plugins via chrome-extension protocol handler vulnerability

Project Member Reported by rob@robwu.nl, Oct 19 2014

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:
http://www.chromium.org/Home/chromium-security/reporting-security-bugs


VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.
The chrome-extension: and chrome-extension-resource: protocol handlers inherits from the file:-protocol handler.
On Windows, the file:-protocol handler has a special case for .lnk files (see URLRequestFileJob::IsRedirectResponse). These shortcuts are automatically resolved and treated as a redirect. Consequently, chrome-extension://EXTENSIONID/shortcut.lnk URL will be resolved to a file://-URL.

Thanks to the tight security checks for file:-URLs in ResourceLoader::OnReceivedRedirect, this bug does not create an issue for most process types. NPAPI plugins are exempt from these security checks though, so programs that use these plugins can bypass the file:-scheme restriction on Windows computers (even if the plugin runtime restricts file:-access).

The IShellLink API is used to resolve .lnk files, which is not limited to absolute paths. So even with little knowledge of the filesystem structure, an attacker can read many sensitive files. (IShellLink - http://msdn.microsoft.com/en-us/library/windows/desktop/bb776891.aspx).

VERSION
Google Chrome Stable 38.0.2125.104 (Official Build 290379)
OS      Windows (tested with XP and Windows 7)
Flash   15,0,0,189

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

Steps to reproduce:
I guess that Flash is the most popular and innocuous-looking NPAPI plugin, so here is a PoC for Flash.

1. Install NPAPI Flash from http://get.adobe.com/flashplayer/.
2. Disable PPAPI Flash.
3. Load the attached extension:
   - Visit chrome://extensions
   - Enable developer mode
   - Load unpacked extension
   - Select the directory that contains the extracted zip file.
4. After loading the extension, the extension will automatically open the HTML file in a new tab that embeds the Flash object.
5. This Flash object just loads the extension resource (shortcut.lnk). shortcut.lnk point to C:\boot.ini. You can change the shortcut to anything else to see the contents of your file exposed.

See winxp.png and win7.png for screenshots of the PoC in action.


(Flash code (Main.as) based on http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLRequest.html#includeExamplesSummary and http://stackoverflow.com/a/5994185)

I have added the Flash label to this bug because I've confirmed the vulnerability in Flash, but the bug probably affects other NPAPI plugins such as Java.

I found this issue when I was working on  bug 388852 , so a patch is underway.
 
proof-of-concept.zip
3.1 KB Download
Main.as
2.3 KB Download
winxp.png
8.9 KB View Download
win7.png
13.5 KB View Download

Comment 1 by rob@robwu.nl, Oct 19 2014

Cc: miket@chromium.org abarth@chromium.org kalman@chromium.org
CC reviewers of my patch at https://codereview.chromium.org/650453003/ for the full context (not sure if you are otherwise able to view this restricted bug).

Comment 2 by kalman@chromium.org, Oct 20 2014

"Consequently, chrome-extension://EXTENSIONID/shortcut.lnk URL will be resolved to a file://-URL"

That seems like the bug to me, it sounds like it should resolve to a chrome-extension URL.

Comment 3 by rob@robwu.nl, Oct 20 2014

> "Consequently, chrome-extension://EXTENSIONID/shortcut.lnk URL will be resolved to a file://-URL"
>
> That seems like the bug to me, it sounds like it should resolve to a chrome-extension URL.

These lnk files (Windows shell links) shouldn't be resolved at all. The network layer automatically follows the redirect to file://, and sends the file content back to the requestor (provided that the redirect is not cancelled, which is the case for NPAPI plugin requests).
Project Member

Comment 4 by bugdroid1@chromium.org, Oct 20 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54a4e4044b90ab88d59af098586cd82bc1cfac8e

commit 54a4e4044b90ab88d59af098586cd82bc1cfac8e
Author: rob <rob@robwu.nl>
Date: Mon Oct 20 20:52:51 2014

Override IsRedirectResponse in extension protocols

The default URLFileRequestJob::IsRedirectResponse implementation is incorrect
for URLRequestExtensionJob (chrome-extension:-scheme) and ExtensionResourcesJob (chrome-extension-resource:-scheme).

BUG= 388852 , 424961 

Review URL: https://codereview.chromium.org/650453003

Cr-Commit-Position: refs/heads/master@{#300329}

[modify] https://chromium.googlesource.com/chromium/src.git/+/54a4e4044b90ab88d59af098586cd82bc1cfac8e/chrome/browser/extensions/extension_resource_protocols.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/54a4e4044b90ab88d59af098586cd82bc1cfac8e/extensions/browser/extension_protocols.cc

Comment 5 by rob@robwu.nl, Oct 21 2014

This bug can be exploited by extensions in the Chrome web store.

1. Install NPAPI Flash from http://get.adobe.com/flashplayer/.
2. Disable PPAPI Flash.
3. Install https://chrome.google.com/webstore/detail/chrome-extension-url-vuln/gjbmlcpdjkpggogpelningaffklocbai
4. Observe that the contents of %WINDIR%\system32\drivers\etc\hosts is displayed by the extension (see attached screenshot).
poc-hosts-file.zip
3.6 KB Download
win7_hostsfile.png
28.9 KB View Download
Labels: Security_Severity-Low Security_Impact-Stable

Comment 7 by rob@robwu.nl, Oct 21 2014

Labels: Merge-Requested M-38 M-39
Request to merge 54a4e4044b90ab88d59af098586cd82bc1cfac8e.
Answers to merge questions:
1. Yes
2. No.
3. Yes, me. The patch is relatively simple, so the risk of merging is also low.
4. The bug allows attackers to read local files on Windows.
Labels: -Merge-Requested Merge-Approved
merge approved for m39 branch 2171.  please remember to reset the merge-request label for M38 owner to evaluate as well and wait for word from matthewyuan@ prior to making changes for M38.

Comment 9 by rob@robwu.nl, Oct 22 2014

Labels: -Merge-Approved Merge-Requested
Request to merge 54a4e4044b90ab88d59af098586cd82bc1cfac8e into M38.
Answers to merge questions are in c7.

Comment 10 by rob@robwu.nl, Oct 22 2014

Why is this bug labeled as low severity?

This bug allows for permanent access to any local file if:
1. NPAPI Flash is activated instead of Pepper Flash. Most users will probably not satisfy this condition, but it is still commonly suggested, e.g. as a way fix broken YouTube videos.
2. A malicious Chrome extensions is installed. This extension does not require any install-time permissions, and the thanks to auto-updating, the shortcuts can easily be modified by the extension author. See comment 5 for an unlisted PoC in the Chrome Web Store.

Based on the guidelines at http://www.chromium.org/developers/severity-guidelines, I would rate this bug as High ("read confidential data"), or at least Medium ("High, but requires unusual user action"; assuming that disabling PPAPI Flash is a unusual).
Labels: -Security_Severity-Low Security_Severity-Medium
I marked it as low because it requires an extension install and NPAPI Flash, but medium definitely seems reasonable given the potential impact.

Comment 12 by amin...@google.com, Oct 28 2014

Labels: m39-ignore
Adding an ignore label for M39 so I don't have to look at this every day.

Rob, have you merged this to M39 yet?  Can you please do so ASAP if not done already?

Comment 13 by rob@robwu.nl, Oct 28 2014

@amineer
So far, whenever my merge request was approved, the bug drone soon followed up with a comment that the patch was merged. I thought that this was automatically done by the one who approves the merge, but apparently not.

So, how can I merge the patch into M39?
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 31 2014

Labels: merge-merged-2171
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9929eff121903c9a3c627696fd91b9082c1d372b

commit 9929eff121903c9a3c627696fd91b9082c1d372b
Author: Rob Wu <rob@robwu.nl>
Date: Fri Oct 31 15:26:58 2014

Override IsRedirectResponse in extension protocols

The default URLFileRequestJob::IsRedirectResponse implementation is incorrect
for URLRequestExtensionJob (chrome-extension:-scheme) and ExtensionResourcesJob (chrome-extension-resource:-scheme).

BUG= 388852 , 424961 

Review URL: https://codereview.chromium.org/650453003

Cr-Commit-Position: refs/heads/master@{#300329}
(cherry picked from commit 54a4e4044b90ab88d59af098586cd82bc1cfac8e)

Review URL: https://codereview.chromium.org/690313002

Cr-Commit-Position: refs/branch-heads/2171@{#317}
Cr-Branched-From: 267aeeb8d85c8503a7fd12bd14654b8ea78d3974-refs/heads/master@{#297060}

[modify] https://chromium.googlesource.com/chromium/src.git/+/9929eff121903c9a3c627696fd91b9082c1d372b/chrome/browser/extensions/extension_resource_protocols.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/9929eff121903c9a3c627696fd91b9082c1d372b/extensions/browser/extension_protocols.cc

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 16 by bugdroid1@chromium.org, Nov 4 2014

Labels: -Merge-Approved merge-merged-2125
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5e1d4f01be1cabde46f2f99b527a31593c6b33fa

commit 5e1d4f01be1cabde46f2f99b527a31593c6b33fa
Author: Rob Wu <rob@robwu.nl>
Date: Tue Nov 04 22:58:36 2014

Override IsRedirectResponse in extension protocols

The default URLFileRequestJob::IsRedirectResponse implementation is incorrect
for URLRequestExtensionJob (chrome-extension:-scheme) and ExtensionResourcesJob (chrome-extension-resource:-scheme).

BUG= 388852 , 424961 

Review URL: https://codereview.chromium.org/650453003

Cr-Commit-Position: refs/heads/master@{#300329}
(cherry picked from commit 54a4e4044b90ab88d59af098586cd82bc1cfac8e)

Review URL: https://codereview.chromium.org/702673003

Cr-Commit-Position: refs/branch-heads/2125@{#598}
Cr-Branched-From: b68026d94bda36dd106a3d91a098719f952a9477-refs/heads/master@{#290040}

[modify] https://chromium.googlesource.com/chromium/src.git/+/5e1d4f01be1cabde46f2f99b527a31593c6b33fa/chrome/browser/extensions/extension_resource_protocols.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/5e1d4f01be1cabde46f2f99b527a31593c6b33fa/extensions/browser/extension_protocols.cc

Comment 17 by rob@robwu.nl, Nov 4 2014

Status: Fixed
Project Member

Comment 18 by ClusterFuzz, Nov 5 2014

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: Release-0-M39
Labels: reward-topanel
Labels: -reward-topanel reward-ineligible
Thanks for the report. Unfortunately, this one did not qualify for a reward due to the small percentage of users with NPAPI flash installed coupled with the requirement of installing an extension.
Project Member

Comment 22 by ClusterFuzz, Feb 11 2015

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 23 by sheriffbot@chromium.org, Oct 1 2016

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
Project Member

Comment 24 by sheriffbot@chromium.org, Oct 2 2016

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
Labels: allpublic

Sign in to add a comment