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."'"
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...
It appears to manifest on Mac as well. Read more.
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.
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.
So Linux really is more secure than Windows! ;)
You, er, left out a '+' in the above URL. Go figure.