Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug Chrome Google Security IT Technology

Bug Opens Chrome to Easy Remote Code Execution 61

Posted by Unknown Lamer from the social-engineering-never-works dept.
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."'"
This discussion has been archived. No new comments can be posted.

Bug Opens Chrome to Easy Remote Code Execution More

Bug Opens Chrome to Easy Remote Code Execution

Comments Filter:

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

  • Whooops :) Shit happens LOL

  • Go figure.

  • Easy? (Score:5, Informative)

    by The MAZZTer ( 911996 ) <megazzt@nospAm.gmail.com> on Monday October 24, 2011 @10:48AM (#37818878) Homepage

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

    • 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? (Score:4, Informative)

        by BZ ( 40346 ) on Monday October 24, 2011 @11:17AM (#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.

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

    • 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 re

      • Re: (Score:3)

        by josath ( 460165 )
        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

        • 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!

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

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

        • Re: (Score:2)

          by erice ( 13380 )

          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.

          • 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: (Score:2)

              by erice ( 13380 )

              I run stable.

              google-chrome is masked
              Firefox is 3.6.20

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

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

    • > 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 bu

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

      • 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 t

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

    • Comment removed based on user account deletion

    • 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 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 s

    • 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

  • Not seeing any criticality here. (Score:3)

    by _0xd0ad ( 1974778 ) on Monday October 24, 2011 @01:44PM (#37821578) Journal

    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.

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

    • Re: (Score:1)

      by dalias ( 1978986 )
      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?

      • Am I missing something?

        Yes. The default download directory is not Chrome's default working directory.

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

Slashdot Top Deals

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse

Close