Beta
×

### Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

# Bug Opens Chrome to Easy Remote Code Execution

#### Unknown Lamer posted more than 2 years ago | from the social-engineering-never-works dept.

61

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."'"

cancel ×

### Herp-a-Derp! (-1)

#### Anonymous Coward | more than 2 years ago | (#37818648)

I use Chrome! Herp-a-Derp! Somebody asploit me!

### Unnecessary... (1)

#### MrNthDegree (2429298) | more than 2 years ago | (#37818652)

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...

### Re:Unnecessary... (0)

#### Anonymous Coward | more than 2 years ago | (#37818826)

yay! Lets load 'em off the cloud!

So... no fix?

### Re:Hmmm....... (1)

#### Etraud (2256864) | more than 2 years ago | (#37830714)

i hope not. best browser ever...

### Oh my... (1)

#### Dark Lord of Ohio (2459854) | more than 2 years ago | (#37818832)

Whooops :) Shit happens LOL

Go figure.

### Re:Linux (2)

#### nyfle (1995318) | more than 2 years ago | (#37821964)

So Linux really is more secure than Windows! ;) You, er, left out a '+' in the above URL. Go figure [google.com] .

### Easy? (4, Informative)

#### The MAZZTer (911996) | more than 2 years ago | (#37818878)

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...

### Re:Easy? (2)

#### The MAZZTer (911996) | more than 2 years ago | (#37819012)

Addendum: This appears to be a bug in NSS, which is maintained by Mozilla, not Chrome. It also is reproducible on Mac, not just Windows. In addition it is not considered a security bug and is publicly view-able in the Chrome bug tracker. More reading [google.com] .

### Re:Easy? (3, Informative)

#### BZ (40346) | more than 2 years ago | (#37819354)

NSS is maintained by its module owners, who happen to work at Google at the moment. At least one of them is on the Chrome team.

Mozilla hosts the bug tracker and code repository.

So NSS is maintained by Mozilla about the same way as the Linux kernel is maintained by kernel.org.

### Re:Easy? (1)

#### AZURERAZOR (472031) | more than 2 years ago | (#37819118)

Seems to be a very small subset of users that would be affected. I wonder what % of Chrome users are using a different search engine... I'd bet its a pretty small# on just the first caveat.

### Chrome also runs as root (2)

#### goombah99 (560566) | more than 2 years ago | (#37820062)

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.

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.

### Re:Chrome also runs as root (2)

#### josath (460165) | more than 2 years ago | (#37820864)

Basically they do this because they want to be able to update the browser silently. The update process for firefox involves dialogs popping up, you have to OK them, then next time firefox restarts you have to approve a UAC prompt (on windows at least, I assume some kind of sudo popup on linux/mac). Chrome updates silently in the background, next time you open it you have the new version, but you don't get all sorts of popups and new tabs spamming you about it like with firefox. Also updating chrome doesn't disable half your extensions which is nice.

### Bug or Feature? (1)

#### webnut77 (1326189) | more than 2 years ago | (#37821240)

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!

### Re:Chrome also runs as root (1)

#### marcello_dl (667940) | more than 2 years ago | (#37821820)

A many kloc network client and the choice to either run it with root privileges or update it with a popup...
In my universe the answer would be DROP ROOT PRIVILEGES OBVIOUSLY... or install an updater and run that one only as root.

web2py, a python project, autoupdates and I don't recall having seen anything about running as root on windows. If so, why google can't do that too...

### Re:Chrome also runs as root (2)

#### Nimatek (1836530) | more than 2 years ago | (#37821114)

Why would you run it as root for the update function instead of using your distro's repositories?

### Re:Chrome also runs as root (0)

#### Anonymous Coward | more than 2 years ago | (#37821914)

I know it's hard to imagine, but not everyone uses Linux and Chrome runs on more than just Linux. And other operating systems have root as well, even if some of them give it a different name (such as "Administrator" ... certainly not as descriptive a name as "root" but it's a similar idea).

### Re:Chrome also runs as root (1)

#### erice (13380) | more than 2 years ago | (#37821938)

Why would you run it as root for the update function instead of using your distro's repositories?

1. The repository might not be current with Google rapid-fire release schedule
2. You might want Chrome rather than Chromium

I was rather surprised to note that Gentoo was current with Chromium. Firefox is still at 3.6.20. Still no Chrome though.

### Re:Chrome also runs as root (0)

#### Anonymous Coward | more than 2 years ago | (#37822664)

Why would you run it as root for the update function instead of using your distro's repositories?

1. The repository might not be current with Google rapid-fire release schedule
2. You might want Chrome rather than Chromium

I was rather surprised to note that Gentoo was current with Chromium. Firefox is still at 3.6.20. Still no Chrome though.

you still would not run it as root and AFAIK no linux build of chrome contains the auto updating pieces. also if your distro uses either deb or rpm you could just use google's own repository: http://www.google.com/linuxrepositories/ [google.com]

### Re:Chrome also runs as root (1)

#### simcop2387 (703011) | more than 2 years ago | (#37823608)

Firefox was updated to 7.0 fairly quick after release, same with 6.0 and 5.0. 4.0 has been too long for me to remember how long it took. http://packages.gentoo.org/package/www-client/firefox [gentoo.org]

Chrome I can't comment on how quickly it stays updated but it is very much in the package manager. http://packages.gentoo.org/package/www-client/google-chrome [gentoo.org]

### Re:Chrome also runs as root (1)

#### erice (13380) | more than 2 years ago | (#37824694)

I run stable.

Firefox is 3.6.20

### Re:Chrome also runs as root (1)

#### simcop2387 (703011) | more than 2 years ago | (#37835864)

As far as google-chrome goes only the alpha builds are hard masked.

As for them not being in stable I can't say I know, but the issue appears to be one similar to not wanting to enable backports in debian and not understanding why you're also still one Firefox (sorry, iceweasel) 3.6.20. It sounds like a non-issue to me.

You can also specify that you want the "unstable/testing" versions of those packages fairly easily and painlessly.

### Re:Chrome also runs as root (1)

#### metrix007 (200091) | more than 2 years ago | (#37821192)

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.

### wrong (0)

#### Anonymous Coward | more than 2 years ago | (#37821486)

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.

### Re:wrong (1)

#### metrix007 (200091) | more than 2 years ago | (#37826002)

On Windows at least this is certainly not true, as it installs as a standard user without ever requiring an elevation prompt.

### Re:Chrome also runs as root (0)

#### Anonymous Coward | more than 2 years ago | (#37823834)

Are you sure?

I just checked where Chrome is installed on my computer and it is installed in:

Which means that it shouldn't need any special privileges to update itself.

Furthermore, on Linux, Chrome adds its own repository to your package manager, so it gets updated just like any other program you install on Linux, except straight from Google's servers.

### Re:Chrome also runs as root (0)

#### Anonymous Coward | more than 2 years ago | (#37824492)

On mac osx it installs in /Applications requires root.

### Re:Chrome also runs as root (2)

#### Stormtrooper42 (1850242) | more than 2 years ago | (#37824360)

Not on Windows
You get UAC popups in Firefox because it is installed in %ProgramFiles%
You don't get UAC popups with Chrome because it is installed in %UserProfile%\AppData\Local\

Chrome doesn't have any administrative privileges.

### Re:Easy? (1)

#### sl4shd0rk (755837) | more than 2 years ago | (#37820464)

> The link indicates it is far from easy.

That's more of an argument for security through obscurity.

Chrome implements Native Code Execution* in a web browser and it was a bone-headed move from the start. The only technology I can think of that may be more idiotic is executing code handed off from an email attachement. And look where that got us. Google assumed a huge liability implementing NCE and this proves you cannot take that kind of gamble because you simply cannot make a guarantee about absolute bug-free code.

[*] - http://www.theregister.co.uk/2010/06/25/mozilla_on_npapi_pepper/ [theregister.co.uk]

### Re:Easy? (1)

#### James Carnley (789899) | more than 2 years ago | (#37820800)

This has nothing to do with NaCl (which I'm assuming you are referring to by "native code execution") and you should be ashamed for trying to pin this on it. Feel free to actually read the whitepapers on NaCl and look into the internals of how it works.

### Re:Easy? (1)

#### Bucky24 (1943328) | more than 2 years ago | (#37820884)

NaCL = http://en.wikipedia.org/wiki/Sodium_chloride [wikipedia.org] , ie table salt

### Re:Easy? (0)

#### Anonymous Coward | more than 2 years ago | (#37820966)

No, that's NaCl, and it has absolutely fuck-all to do with what we're talking about regardless of whether you were making a shitty joke or not.

### Re:Easy? (0)

#### Anonymous Coward | more than 2 years ago | (#37829206)

go suck a dick, aspie

### Re:Easy? (0)

#### Anonymous Coward | more than 2 years ago | (#37862706)

Well done for remembering (or looking up) the chemical abbreviation of sodium chloride, have a cookie.

More educated people here would also know it is also the abbreviation Google uses for Native Client [wikipedia.org] .

### Re:Easy? (1)

#### nahdude812 (88157) | more than 2 years ago | (#37821504)

That's more of an argument for security through obscurity.

No, it's saying that something which requires an extremely elaborate feat of social engineering and even when pulled off successfully is able to affect only a small fraction of the user base, and only some of the time, is not very much of a security risk. It's undesirable behavior which they should probably change, but the chances of successfully exploiting it are vanishingly small, particularly compared to alternate attacks with much greater efficacy and lower threshold for success, and which are easier to exploit (namely social engineering in general, i.e. "run this .exe file I'm going to send you").

### Grandma (1)

#### Kamiza Ikioi (893310) | more than 2 years ago | (#37821750)

Yeah, I don't quite see Grandma falling for this... she couldn't even understand the instructions, let alone be fooled into doing this.

### Re:Easy? (2)

#### hairyfeet (841228) | more than 2 years ago | (#37823728)

If they have to do all of that? Its pointless there are easier ways to pwn a machine. For Windows its as easy as "ZOMG! You got teh viruz! Run "Iz_Not_Viruz_iz_Cleaner.exe' to kill it ZOMG!" or "U want teh tittez and lezbos? We got teh tittez and lezbos and so can u! Just run "Iz_Not_Bug_iz_Codec.exe' and enjoy all teh tittez and lezbos today!" and for Linux the social engineering is a little different but idea is the same [geekzone.co.nz] and the end result is a pwned machine, see the KDE screensaver malware that went around a couple of years back, or the infected Q III arena code that actually was sitting on one of the repos being passed out for quite awhile before it got caught.

In the end it would simply be easier to get the user to help pwn the machine FOR you than jump through this many hoops. Hell between social engineering, adobe products, and "JavaScript malware o' the day" there are now more than ever far easier ways to make a machine yours than deal with THIS much hoop jumping, it simply wouldn't be worth the effort if you can't somehow automate it.

### Re:Easy? (1)

#### scdeimos (632778) | more than 2 years ago | (#37826576)

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.

I'm curious why TFA didn't mention this: unless Chrome overwrites pkcs11.txt on each start, which I don't believe it does, then the modified pkcs11.txt will still be there for Chrome to load the next time it's launched.

### Not really that much of an issue (1)

#### Jamiemeister (1724710) | more than 2 years ago | (#37818916)

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.

### Re:Not really that much of an issue (1)

#### ThorGod (456163) | more than 2 years ago | (#37818970)

Yeah, I wish conditions such as that lowered the priority of an exploit.

### Does pkcs11.txt "Reset" After Each Run? (1)

#### Carcass666 (539381) | more than 2 years ago | (#37819082)

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.

### Re:Does pkcs11.txt "Reset" After Each Run? (1)

#### The MAZZTer (911996) | more than 2 years ago | (#37819218)

It sounds like Chrome delays loading NSS until it is needed (for the first HTTPS request made). When NSS loads it loads pkcs11.txt and looks for user-definable configuration settings. The idea of changing the CWD is just because if the hacker can write to C:\pkcs11.txt (where Chrome would look for it assuming Chrome's default installation location) the hacker already has control of the PC. Changing the CWD before the first HTTPS request allows the hacker to control where Chrome looks for that file. The file itself is static and is not changed by NSS I would imagine.

NSS was probably designed with the assumption that it gets loaded on application startup (I imagine Firefox uses it since Mozilla wrote it) and so CWD would never be an issue. Whoops.

### Re:Does pkcs11.txt "Reset" After Each Run? (0)

#### Anonymous Coward | more than 2 years ago | (#37819228)

Chrome doesn't modify pkcs11.txt, it only reads from it. So if you're wondering whether this can also be used by malware to ensure automatic execution every time Chrome is launched, while hiding from anti-malware tools - it can.

### Re:Does pkcs11.txt "Reset" After Each Run? (1)

#### Gaygirlie (1657131) | more than 2 years ago | (#37819334)

So if you're wondering whether this can also be used by malware to ensure automatic execution every time Chrome is launched, while hiding from anti-malware tools - it can.

Only if you can modify the CWD of Chrome at startup.

### Re:Does pkcs11.txt "Reset" After Each Run? (1)

#### Qzukk (229616) | more than 2 years ago | (#37819480)

Only if it can drop pkcs11.txt into the default directory. Otherwise, it goes back to hoping that the user doesn't go to any ssl sites until after they've disabled google search and saved a file in the malware-controlled directory.

### Hmm (0)

#### bonch (38532) | more than 2 years ago | (#37819602)

Google decided that this was not a vulnerability, but rather a 'strange behavior that [they] should consider changing.'

"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.

### Re:Hmm (1)

#### im3w1l (2009474) | more than 2 years ago | (#37820116)

"It's not a bug, it's a feature! This will make users think twice about changing their search engine preference"

### Re:Hmm (1)

#### Riceballsan (816702) | more than 2 years ago | (#37820944)

Sounds to me more like googles saying this isn't a priority security vulnerability, but a minor bug. Which looking at the necessary hurdles, I can't really disagree with them. Looks like the target vector is people who don't trust google enough to use google but do enough to use chrome. Click links mindlessly but aren't planning to log into hotmail, gmail, facebook, their bank etc... The quanity of potential targets is so small, and the people it would likely target have to be so gullible I can't see this exploit ever being usable in the wild.

### Easy and obscure! (0)

#### Anonymous Coward | more than 2 years ago | (#37820480)

Exactly as intended, no accident, no mistake, configuration certain behavior that works, tested and proven

### Not seeing any criticality here. (2)

#### _0xd0ad (1974778) | more than 2 years ago | (#37821578)

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.

### Easy? (1)

#### flimflammer (956759) | more than 2 years ago | (#37821936)

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.

### Wat? (1)

#### binford2k (142561) | more than 2 years ago | (#37822046)

The OP has an unusual definition of easy.

### Need local access (1)

#### jgoemat (565882) | more than 2 years ago | (#37823240)

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.

### Re:Need local access (1)

#### dalias (1978986) | more than 2 years ago | (#37823964)

This sounds pretty easy actually. First serve the user the malicious file named "pkcs11.txt" or whatever it needs to be, with a binary content-type so it gets saved (presumably in the default download directory) rather than displayed, and then go from there. Am I missing something?

### Re:Need local access (1)

#### _0xd0ad (1974778) | more than 2 years ago | (#37830512)

Am I missing something?

### Re:Need local access (1)

#### DragonWriter (970822) | more than 2 years ago | (#37824130)

To work, the attacker needs to have planted two files somewhere that can be set to the working directory for chrome.

Note quite: the first of them has to be in the root of the CWD (e.g., on Windows, if the CWD is C:\foo\bar\baz, the file has to be in C:\), and the other one can be anywhere, since its accessed by an address provided in the first file.

### It's not a vulnerability... (0)

#### Anonymous Coward | more than 2 years ago | (#37830756)

It's a browser wardrobe malfunction.

# Slashdot: News for Nerds

Man is an animal that makes bargains: no other animal does this-- no dog exchanges bones with another. -- Adam Smith

Need an Account?

# Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

• b
• i
• p
• br
• a
• ol
• ul
• li
• dl
• dt
• dd
• em
• strong
• tt
• blockquote
• div
• quote
• ecode

### "ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>