Slashdot Mirror
Bug Opens Chrome to Easy Remote Code Execution
Orome1 writes "ACROS Security notified Google about a peculiar behavior of the 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. Google decided that this was not a vulnerability, but rather a 'strange behavior that [they] should consider changing.' The reason they provided was that 'the social engineering level involved here is significantly higher than "Your computer is infected with a virus, download this free anti-virus software and run the exe file to fix it."'"
Why is that even necessary? Remote libs could be loaded via FUSE/NFS (Linux, Solaris, Mac OS X) mounts or SMB/CIFS (Windows). Not hard to change with no loss of functionality for corporate needs...
So... no fix?
Whooops :) Shit happens LOL
Go figure.
The link indicates it is far from easy. First, the user must not be using Google as the Chrome search engine, nor have used HTTPS at all during the browsing session, as either causes the window of opportunity to close until Chrome is restarted. Secondly, the attacker must trick the user into moving Chrome's CWD using Open/Save As to a network drive where they have control. THEN the attack is easy as the following HTTPS site the user visits will trigger the loading of arbitrary code controlled by the attacker. But overall it is far easier to trick a user into opening an e-mail attachment or downloading and executing arbitrary code to begin with imo...
Not really an issue when the following 3 prerequisites must be met: Google must not be the selected search engine. User must not have visited any HTTPS resources before the attack. Chrome's current working directory must be set to attacker-controlled location.
The article states that the vulnerability is triggered when a library load is added to pkcs11.txt, and it's really not a problem because as long as you are using Google as a search engine (or anything else that would load up PKCS routines before the pkcs11.txt is modified) then you are not going to run into any problems. But if pkcs11.txt does get modified because the user loads on a malicious payload, does pkcs11.txt somehow reset to its original content when Chrome is shutdown? Or is that library line still there in pkcs11.txt when Chrome restarts?
A configuration file located in a user writable directory seems like an odd place to load up a library, especially one that allows the a library to be loaded from the Internet. "Strange Behavior" seems a bit euphemistic here.
"It's not a bug, it's a feature!"
It's amusing when Google avoids labeling vulnerabilities. My favorite is when Flash had a vulnerability, and Google denied it should be considered a Chrome vulnerability even though Chrome bundles Flash for some ungodly reason.
Go figure.
Ironically Chrome magnifies the importance of security holes that escape the sandbox by it's design. Chrome retains root privledges by default. you can turn this off but then it won't update. That is chromes update manager downloads and installs and exectutes code automatically with root privledges. it does not require you to enter your password to do this.
Thus if an exploit can re-direct chrome into trusting other URLs than it should it's var more of a security hole than it would be if chrome did not retain root privledges.
Note that many codes check for updates: ms word, firefox, and some even download the updates ahead of time. But only chrome installs and runs these as root without asking for your password.
Basically it's unsafe to use chrome in any corporate or government environment
Chrome is invasive in many ways. It even modifies your Environment variables on Macs.
Some drink at the fountain of knowledge. Others just gargle.
Exactly as intended, no accident, no mistake, configuration certain behavior that works, tested and proven
but you don't get all sorts of popups and new tabs spamming you about it like with firefox.
Is this a bug or feature?
I vote bug!
There are no root privileges. Chrome runs as a local user and installs to a local user directory, which is why you don't need root privs to update it. Stop spreading misinformation.
Sorry you are utterly wrong. By default, Chrome's update manager runs as a root daemon on mac and linux. it's well documented, and Google acknowledges this.
This "hack" requires user-level privileges. "User-level" means equivalent to a non-administrator running a .exe file.
Chrome resides in the user folder rather than the Program Files folder. This is by design: a non-administrator user can install and update Chrome, without the installer/updater having to ask for administrator privileges.
In other words, if user-level code can update Chrome, user-level code can just as easily mess with Chrome itself. Or, for that matter, encrypt the user's data files using long encryption keys, then pop up messages telling the user "pay us $50 and we'll give you the encryption key to get your data back". Yes, that's a problem, and the problem is users who run executable files that they shouldn't. While non-administrator users shouldn't have the ability to hose their OS, they can easily hose their data. Since Chrome resides (by design) in their "data", obviously they can hose Chrome. This is no surprise.
Furthermore, web pages shouldn't be able to get user-level privileges. They'd first have to break out of the browser's sandbox. So this isn't actually remote code execution, unless there's some way to remotely execute user-level code already. And when one of those leaks is found, you bet it's a critical bug and they'll immediately start writing a patch for it.
Both this "leak" and the "floodgates" are already protected by what already protects the user from any random .exe file found on the web: the browser's sandbox, and the user himself.
Yeah, I don't quite see Grandma falling for this... she couldn't even understand the instructions, let alone be fooled into doing this.
I8-D
Unless I've missed something, the steps to cause this are long and specific, requiring a pretty much already compromised machine to cause. Not really seeing the ease, here. Or for that matter the criticality.
I agree with Google on this one.
The OP has an unusual definition of easy.
To work, the attacker needs to have planted two files somewhere that can be set to the working directory for chrome. Then they need to get the user to download a file to that same directory in order to make it the working directory. Then they need to get the user to visit an SSL site, but the user cannot be using google as their search engine and the user cannot have visited another SSL site prior to changing working directories.
If an attacker has access to the local filesystem, you've already been exploited.
It's a browser wardrobe malfunction.