Disputed / BOGUS
Google Chrome pkcs11.txt File Planting
| Published / (Updated)||Credit
|2011-11-03 / 2012-03-12
|CVSS Base Score
Chrome 15, released two days ago, makes this bug even harder to exploit as its phishing and malware protection (enabled
by default in Chrome's Under the Hood options) now sends an HTTPS request to one of its servers immediately upon
startup. Therefore, in addition to not having Google as the search engine and not having visited any HTTPS addresses
before the attack, the user would also have to disable phishing and malware protection in order for this bug to be
Thirty days ago our company notified Google about a peculiar behavior of Chrome browser that can be exploited for
execution of remote code outside Chrome sandbox under specific conditions. It is another case of file planting, where an
application loads a data file (as opposed to binary file, leading to binary planting) from the current working
directory. Similarly to our previously reported file planting in Java Runtime Environment (still there in current build
1.6.0_29 if you want to play with it), Chrome loads a data file, namely pkcs11.txt, from the root of the current working
directory and in case the file exists, parses and processes its content. Security-wise, the most interesting value in a
pkcs11.txt file is called library. Consider the following line in pkcs11.txt:
This line will instruct Chrome to load library c:\temp\malicious.dll. To allow remote code execution attacks, it works
with remote shared folders too; in our demonstration, the following line is used:
In addition, the library file doesn't have to have a known extension (such as ".dll"), which makes it harder
to block it on a firewall.
Finally, Chrome sandbox doesn't provide any protection here as the entire process of loading pkcs11.txt and the
associated library is done by the parent chrome.exe process.
HTTPS, NSS And pkcs11.txt
Chrome loads "/pkcs11.txt" the first time it needs to do anything encryption-related, which in most cases
means visiting an HTTPS URL. Chrome developers tracked this issue to one of Mozilla's Network Security Services (NSS)
libraries, and it seems that it is a matter of unfortunate circumstances that gave life to this bug in Chrome, although
the same bug may potentially exist in some other products integrating NSS libraries.
If you carefully read the previous paragraph, you noticed two things:
Chrome loads pkcs11.txt the first time it needs PKCS #11 capabilities, and it never does it again until re-launched.
This means that if the user has already visited an HTTPS address before, or any of the sites he visited has loaded an
image or any other data via HTTPS, the attack opportunity is gone. What makes things worse for the attacker is the fact
that when Google is the selected search engine - and it is by default -, Chrome sends a request to
https://www.google.com/searchdomaincheck... to determine your local Google domain immediately upon startup. This
triggers the loading of pkcs11.txt from the root of user's local system drive and closes the attacker's window of
opportunity before it was ever really opened.
The initial forward slash in the file name "/pkcs11.txt" means that pkcs11.txt will be loaded from the
root of the current working directory, and not from the current working directory. For instance, if current working
directory is C:\users\james\, Chrome will try to load C:\pkcs11.txt. In a shared folder case, if current working
directory is \\server\share\somefolder\, Chrome will try to load \\server\share\pkcs11.txt.
So how can this vulnerability be exploited? Three conditions need to be met:
Google must not be the selected search engine. This setting is configurable under the Options page, and users can
set Yahoo, Bing, or any other search provider as their selected search engine. We confirmed that Yahoo and Bing don't
send any HTTPS requests when Chrome is launched and are therefore suitable for mounting the attack.
User must not have visited any HTTPS resources before the attack. As described above, the attack relies on the fact
that the NSS capabilities have not been initialized yet in the running parent Chrome process. Ideally for the attacker,
the user would have just launched Chrome and not visit any web sites that send HTTPS requests.
Chrome's current working directory must be set to attacker-controlled location. Since Chrome sets its current
working directory to its own folder on user's machine upon startup, double-clicking on HTML file in a remote shared
folder (which often works for binary planting attacks) wouldn't achieve anything for the attacker. The best remaining
way we know of to set the current working directory in Chrome are then the file browse dialogs. If the attacker could
get the user to try to load a file from her network shared folder, and trigger the first HTTPS request while the user
had this folder opened in the "Open" dialog, Chrome would load pkcs11.txt from the root of attacker's network
share and load the library specified in it.
See this note in TXT Version