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 1 user
Status: Fixed
Last visit 27 days ago
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Chrome attempts to load metro_driver.dll when Metro is not supported
Reported by, May 30 2012 Back to list
Driver metro_driver.dll is susceptible to library hijack.

Chrome Version: 19.0.1084.52 m stable
OS Name:        Microsoft Windows 7 Enterprise
OS Version:     6.1.7601 Service Pack 1 Build 7601

For actual reproduction all you need to do is to run chrome.exe.

To notice the finding follow those steps:
(1) Capture events using sysinternals' procmon.exe
(2) Run chrome.exe, wait for completion
(3) Under procmon - Filter according to Path that contains metro_driver.dll

Type of crash: none

Comment 1 by, May 30 2012
Status: Invalid
If you have permission to write arbitrary DLLs to these paths then you have sufficient permission to replace the Chrome install or other essential binaries.
Comment 2 by, May 31 2012
That's not correct. The DLL is loaded by an old-school search function that traverses the PATH environmental variable, and its components are determined on every computer system individually.
Comment 3 by, May 31 2012
Based on my analysis there's no way to hijack any of the DLL loads without without modifying either the user's environment, a path in the user's profile, or a system path. Any of those actions requires permission that already indicates an account or system compromise. If you have a proof of concept demonstrating the contrary, then I'll gladly reopen the bug.
Comment 4 by, May 31 2012
1) the matter of this type of traversal until match is unsafe, and Microsoft points out the risk and measures of fixing it here:

2) The PATH environmental variable is up to change and de-facto many times contains a path that is world-writable, it's not something that is up to chrome to decide and thus is not something to be trusted as safe, in general.
Comment 5 by, May 31 2012
Hopefully I can explain a bit better. The first paths searched are in either the user's profile or "Program Files" (depending on the installation). After that various system directories are searched. So, the first step in an attack would be deleting a DLL from a user's private directory or a protected directory, both of which imply a more significant compromise. Only after that is the PATH variable searched, and even then it doesn't include any world-writable paths in its default configuration. So, I can't really see a circumstance in which this is practically exploitable. As I mentioned previously, I'm happy to reopen the bug if you demonstrate that you can hijack a DLL.
Comment 6 by, May 31 2012
I see, but the only problem is that metro_driver.dll is not actually present under my win7sp1 x64 - 19.0.1084.52 installation, nonetheless - chrome.exe tries to load it, thus resulting in traversing PATH.
Status: Unconfirmed
@cpu, @ananta - None of the Metro code should be enabled on stable channel. Did something get left on that shouldn't be?

I'd still keep this as severity-none because it requires local access and isn't a vulnerability in a default configuration. However, we shouldn't be attempting to load this DLL on stable channel at all.
Comment 8 by, Jun 2 2012
1) I've noticed that someone have posted an exploit to this finding, hours after my disclosure here:
2) The notion of loading an non-present DLL is considered a vulnerability without a doubt, the only thing that is affecting the low score of this vuln. is the probability - which is unlikely to happen but still possible (as a penetration tester, I see many systems with flowed PATH, btw).
The overall severity calculation by a simple risk matrix will give you Moderate severity.
Comment 9 by, Jun 2 2012
Reverted this code in the m19 branch.

Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals Merge-Merged Mstone-19 OS-Windows SecSeverity-Low
Summary: Chrome attempts to load metro_driver.dll when Metro is not supported (was: NULL)
As I mentioned before, if you have a PoC that demonstrates an actual vulnerability on a normal configuration then I'll happily reevaluate. However, the link you provided simply notes the same details as your original report, without addressing the impracticality of an actual exploit. As for the larger explanation of why we would not treat this as a vulnerability, it amounts to the potential attack scenarios:

1) You can write files to private or system paths, in which case the system is already compromised.
2) Your path variable contains attacker controllable directories, in which case you already have a dangerous configuration vulnerability.
3) A victim can be enticed to execute a shortcut that runs chrome.exe inside an attacker-controlled directory, in which case the victim could as easily be convinced to run a malicious executable directly.

That stated, I reopened the bug because I hadn't originally realized your report was made against Chrome 19. Our metro support is experimental, and hasn't be reviewed for release yet. So, Chrome 19 shouldn't be trying to load a DLL we aren't supposed to be shipping in the first place. While I don't see an immediate vulnerability in that scenario, it's certainly a dubious practice. So, out of an abundance of caution I'm marking this as low-severity.

Thank you for your report and we've removed the offending code from the stable branch. It should be addressed in the next Chrome 19 update, and please let us know how you would like to be credited in the release notes.

Comment 11 by, Jun 3 2012
It should read:
Moshe Zioni (Comsec Consulting)

BTW, When (in terms of version numbers) the metro_driver.dll was added to stable?

Thank you.
Comment 12 by, Jun 4 2012
zimoshe, the dll is not yet shipping on any version of chrome. When the code was added can be found via svn.

Comment 13 by, Jun 11 2012
The issue will be reported under identifier CVE-2012-2764 which is currently reserved by me, please ref. it in the update notes. Thank you
Labels: -Mstone-19 Mstone-20 CVE-2012-2764
Status: FixUnreleased
Tagging this bug with your CVE, thanks!
This will get announced / credited in the release notes for Chrome 20, although some code was already removed in the Chrome 19 branch.

Justin / Carlos -- seems like we've taken action here so this bug should be some sort of fixed?
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member Comment 16 by, 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.
Status: Fixed
Project Member Comment 18 by, Mar 10 2013
Labels: -Type-Security -Area-Internals -Mstone-20 -SecSeverity-Low Security-Severity-Low M-20 Cr-Internals Type-Bug-Security
Project Member Comment 19 by, Mar 13 2013
Labels: Restrict-View-EditIssue
Project Member Comment 20 by, Mar 14 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member Comment 22 by, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 23 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 24 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
Sign in to add a comment