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
Status: Fixed
Owner:
Closed: Apr 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Security: MSVR:159 - Google Chrome NPAPI Plugin Insecure Loading Elevation of Privilege Vulnerability
Reported by msvulner...@gmail.com, Apr 19 2012 Back to list
=================================
The following Software vulnerability report is highly confidential and should be limited in distribution to members of the engineering team within your organization with need-to-know for performance of security risk analysis and remediation. Please do not distribute outside of your organization. The attached research report is likewise highly confidential and its existence and contents should not be discussed outside of your organization's security team and the report itself limited in distribution to those individuals with need-to-know clearance.

For legal and business continuity reasons, to ensure consistency, and to limit the circle of knowledge about this vulnerability, we ask you to please direct all communications through msvr@microsoft.com and not to the individual finder or other contacts.

Please acknowledge this report via email to msvr@microsoft.com
==================================


MSVR Case #:  159
Title: Google Chrome NPAPI Plugin Insecure Loading Elevation of Privilege Vulnerability
Version Tested: Google Chrome 17.0.963.79 on Windows
Impact: Elevation of Privilege
Finder/Credit:  Haifei Li at Microsoft and Microsoft Vulnerability Research (MSVR)
CVE:  Pending


Summary:
An elevation of privilege vulnerability exists in Google Chrome due to the insecure loading of NPAPI plugins on Chrome. An attacker who successfully exploited this vulnerability could run arbitrary code with elevated privileges.

Technical Details:
When Chrome is being started, it searches in the following directories on every hard drive trying to find a NPAPI plugin which is named like "NP*.DLL".
   
                X:\PFiles\Plugins\NP*.DLL

Following is the behavior caught by "file monitor" tools:

                D:\PFiles\Plugins\                          NO SUCH FILE                    FileBothDirectoryInformation: NP*.DLL


Normally, Chrome will be installed in the current-user's private directory (by default, it's "C:\Users\Administrator\AppData\Local\Google\Chrome"), it's good for keeping the system safe since the low-privilege user would not be able to access the high-privilege user's private directory.

However, the good-security feature will be broke by the NPAPI plugin searching behavior discussed above. The low-privilege user could create such a plugin on the system and wait for the high-privilege user to use Chrome. If some certain conditions are matched, the low-privilege user could gain the same privilege as the high-privilege user.

Following we are going to discuss details regarding the "certain conditions".

At the beginning, when Chrome is being started, it tries to find NPAPI plugins in these directories ("X:\Pfiles\Plugins"), at this time, it won't load them as executable Windows libraries, instead, it tries to find the registered MIME-type which is stored in the resource "VERSION" in the PE file, if the found MIME-type hasn't been registered in any other plugins before, Chrome will use this plugin for handling future such MIME-type contents.

So, let's say, if we registered a MIME "application/x-helloworld" in "D:\PFiles\Plugins\npChromePlugin.dll", in future, when Chrome encounters "application/x-helloworld" contents, it will load the "npChromePlugin.dll", at this time, the malicious code in "npChromePlugin.dll" will be executed directly with the same privilege as the current user.

Please note that Chrome doesn't sandbox NPAPI plugins, which will make the "Elevation of Privilege" performed directly.

For more information regarding NPAPI plugin and Google Chrome as well as how to develop a NPAPI plugin please refer to the following pages:

http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics
https://wiki.mozilla.org/NPAPI


Please note that the attacker could register a (or, many) more-commonly-used MIME-type(s) which will make the attack more easily, the "application/x-helloworld" discussed here is just an example.



How to Reproduce:
We use Windows Server 2008 to show the elevation of privilege more clearly.

1. On Windows Server 2008, create another "Standard user".
2. Log-in as the administrator, install Google Chrome.
3. Log-in as the standard user, create a directory like "X:\PFiles\Plugins" and put the attached file "npChromePlugin.dll" into that directory (You may create "C:\PFiles\Plugins", "D:\PFiles\Plugins", or "E:\PFiles\Plugins").
4. Log-in as the administrator, use Chrome to access the attached file "npapi_plugin_trigger.html" which could be hosted on a web server, or, you can configure your web server in order to make it return "application/x-helloworld" contents. You may access the url like:

                http://192.168.0.1/npapi_plugin_trigger.html                   ("application/x-helloworld" embedded on a web page)
                http://192.168.0.1/npapi_plugin_trigger.helloworld      (accessing a file, being returned as "application/x-helloworld" content)

You will see "calc.exe" is executed finally, you may find that the "calc.exe" process has the same privilege as the current user (administrator).

Proof of Concept Directions:
PoC has password: ms_google


If you have any questions or concerns please contact us via email at msvr@microsoft.com.  In addition, please acknowledge the receipt of this report.

 
Google_Chrome_NPAPI_Plugin_Insecure_Loading_Elevation_of_Privilege_Vulnerability.zip
15.0 KB Download
Comment 1 by jsc...@chromium.org, Apr 19 2012
Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals SecSeverity-Low SecImpacts-Stable OS-Windows Feature-Plugins SecImpacts-Beta
Interesting. We seem to have inherited this from either WebKit or Firefox, and it's present only to support a quirk of how the old Windows Media Player plugin could sometimes be installed. That plugin is woefully out of date and we block anyway. So, it seems safe to just remove the code entirely.
Comment 2 by jsc...@chromium.org, Apr 19 2012
Owner: jsc...@chromium.org
Status: Started
Comment 3 by jsc...@chromium.org, Apr 19 2012
Cc: jam@chromium.org
More interesting... It turns out we added this in 2009 to support the most current Windows Media Player NPAPI plugin (released ~2007). Apparently, if the MS WMP plugin installer doesn't detect Firefox or Chrome, then it drops its files on %SYSTEMROOT%\PFiles\Plugins\. Unfortunately, that location is writable by any authenticated user, so it's always unsafe.

Since there's no safe way to support this installation mechanism, I'm just going to drop it.
Project Member Comment 4 by bugdroid1@chromium.org, Apr 20 2012
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=133096

------------------------------------------------------------------------
r133096 | jschuh@chromium.org | Thu Apr 19 17:24:23 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/npapi/plugin_list_win.cc?r1=133096&r2=133095&pathrev=133096

Don't search root paths for MS WMP plugin

The MS WMP installer will put its binaries in user-writable directories when it doesn't detect a browser to install to. Unfortunately, those directories can be written to by other users on the system and could be used to inject malicious code into another user's Chrome installation. Since there's no safe way to support that install usage, we should just drop it entirely.

BUG= 124216 

Review URL: http://codereview.chromium.org/10123017
------------------------------------------------------------------------
Comment 5 by jsc...@chromium.org, Apr 20 2012
Labels: Merge-Approved Mstone-19
Status: FixUnreleased
This is a trivial change, so we can decide if we want to pick it up for m19 or not.
Labels: -Restrict-View-SecurityTeam -Merge-Approved Restrict-View-SecurityNotify Merge-Merged
r134514
Project Member Comment 7 by bugdroid1@chromium.org, Apr 30 2012
Labels: merge-merged-1084
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=134514

------------------------------------------------------------------------
r134514 | cevans@chromium.org | Mon Apr 30 00:49:23 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1084/src/webkit/plugins/npapi/plugin_list_win.cc?r1=134514&r2=134513&pathrev=134514

Merge 133096 - Don't search root paths for MS WMP plugin

The MS WMP installer will put its binaries in user-writable directories when it doesn't detect a browser to install to. Unfortunately, those directories can be written to by other users on the system and could be used to inject malicious code into another user's Chrome installation. Since there's no safe way to support that install usage, we should just drop it entirely.

BUG= 124216 

Review URL: http://codereview.chromium.org/10123017

TBR=jschuh@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10274003
------------------------------------------------------------------------
Labels: CVE-2011-3098
Comment 9 by cdn@chromium.org, May 15 2012
Status: Fixed
Updating status to Fixed on security bugs which were fixed when m19 went to stable.
Cc: haifei....@gmail.com
CC'ing original reporter.
We should also change the docs that tell users to install this plugin (this is the latest version of the plugin). See  bug 134748 .
Cc: asanka@chromium.org ananta@chromium.org
 Issue 109293  has been merged into this issue.
Project Member Comment 13 by bugdroid1@chromium.org, Oct 13 2012
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 14 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Type-Security -Area-Internals -SecSeverity-Low -SecImpacts-Stable -Feature-Plugins -SecImpacts-Beta -Mstone-19 M-19 Security-Severity-Low Security-Impact-Stable Cr-Content-Plugins Cr-Internals Security-Impact-Beta Type-Bug-Security
Project Member Comment 15 by bugdroid1@chromium.org, Mar 13 2013
Labels: Restrict-View-EditIssue
Project Member Comment 16 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member Comment 18 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 19 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 20 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member Comment 21 by bugdroid1@chromium.org, Apr 6 2013
Labels: Cr-Blink
Project Member Comment 22 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Plugins Cr-Internals-Plugins
Project Member Comment 23 by sheriffbot@chromium.org, Jun 14 2016
Labels: -security_impact-beta
Project Member Comment 24 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 25 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