Slashdot Mirror


New Chrome Exploit Bypasses Sandbox, ASLR and DEP

Trailrunner7 writes "Researchers at the French security firm VUPEN say they have discovered several new vulnerabilities in Google Chrome that enable them to bypass the browser's sandbox, as well as ASLR and DEP, and run arbitrary code on a vulnerable machine. The company said they are not going to disclose the details of the bugs right now, but they have shared information with some of their government customers. The vulnerabilities are present in the latest version of Chrome running on Windows 7, VUPEN said."

29 of 150 comments (clear)

  1. Disclosure policy by Anonymous Coward · · Score: 3, Insightful

    "This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services."

    Oh, I feel SO MUCH better now!

    1. Re:Disclosure policy by Anonymous Coward · · Score: 4, Insightful

      Because ASLR and DEP aren't supposed to be the first line of defense, they are security in depth. The great thing about ASLR, DEP, and "stack canaries" is that you can start using them, and you get a huge amount of protection, -even if you screw up your own code-. The fact that the researchers have to go through the trouble of circumventing ASLR and DEP is a testament to their effectiveness.

      ASLR and DEP just make existing vulnerabilities harder to exploit. Chrome's bug is still the culprit. Microsoft doesn't deserve -any- of the blame here.

    2. Re:Disclosure policy by EvanED · · Score: 3, Informative

      Being able to bypass them is a testament to their bad implementation... ...my understanding is that ASLR's implementation isn't the best, but IMO it's more like "is a testament to the fact that needing ASLR at all is patching a gunshot with a bandaid".

      And you say C++ is insecure and has stupid control structures, but then suggest writing it in C? Really?

    3. Re:Disclosure policy by Rockoon · · Score: 5, Interesting

      Browsers such as Chrome contain memory allocations that avoid DEP by using VirtualProtectEx() as it is pretty much a requirement of JIT compilation.

      Blaming Microsoft in this case is extremely premature, since we know that Chrome does in fact disable some protections intentionally.

      --
      "His name was James Damore."
    4. Re:Disclosure policy by spongman · · Score: 2

      brown hat

      what, like "shit-head" ?

  2. What about Google? by d4fseeker · · Score: 3, Informative

    Funny. I don't read anything about them disclosing it to Google (even tough they offer a bug bounty) So I'll just have to guess NSA and all the other good guys are protecting us (yeah right) until someone at Google stumbles across this issue.

  3. from vulpen site by JonySuede · · Score: 2, Funny

    As the world leader in vulnerability research, VUPEN provides offensive and highly sophisticated exploits specifically designed for Law Enforcement and Intelligence Agencies to help them achieve their offensive missions using tailored and unique codes created in-house by VUPEN.

    God I hate those french researchers, liberty fraternity equality OR DEATH my ass

    --
    Jehovah be praised, Oracle was not selected
    1. Re:from vulpen site by spongman · · Score: 4, Insightful

      wait... in whose screwed up version of utopia do "law enforcement agencies" need "tailored and unique codes" in order to carry out their "offensive missions" ?

      alternative choices:
      1) get a bench warrant.
      2) don't.

  4. Vulnerabilities by magamiako1 · · Score: 2

    Just throwing this out there:

    These problems won't affect 95% of users. Running these sorts of attacks on end users is a bit of a waste, and something this complicated would be saved for more important targets.

    A vast majority of infections out there are things that you're already guarded against if you keep your system updated.

  5. Re:Smug by clang_jangle · · Score: 2

    Still mistaking anyone who triggers your natural feeling of inferiority (that comes with making poor choices) for "smugness", I see. No, we're not smug -- we're just better than you.

    --
    Caveat Utilitor
  6. So... by CrazyDuke · · Score: 3

    You know, when I was demoing Chrome as a possible browser for my tablet, I went looking for a script blocking extension. To my consternation, I was met with the near worthless alternative of either running all scripts or none on a page, either through an extension designed like a high school side-project or using the built in white-listing feature. This is apparently because the API does not allow for functionality along the lines of blocking individual scripts from executing.

    The forums and comments sections addressing user questions as to an alternative usually had self serving replies like "Chrome is so awesome that it doesn't need script blocking." and "It can't be owned due to sand-boxing. You know what sand-boxing is right?" (Because the only reason a person would ask is if they where an ignorant fool, right?)

    So, *cough* tell me why Chrome doesn't need a NoScript-like extension again? @the marketing drones: Because, I'm so sure the cocksure poseur-charisma will scare the crime-ware away, really. The elephant in the room doesn't exist so long as the people that bring it up are shouted down, right?

    --
    Any sufficiently advanced influence is indistinguishable from control.
    1. Re:So... by VortexCortex · · Score: 4, Insightful

      You know, when I was demoing Chrome as a possible browser for my tablet, I went looking for a script blocking extension. To my consternation, I was met with the near worthless alternative of either running all scripts or none on a page, [...]

      So, *cough* tell me why Chrome doesn't need a NoScript-like extension again? @the marketing drones: Because, I'm so sure the cocksure poseur-charisma will scare the crime-ware away, really. The elephant in the room doesn't exist so long as the people that bring it up are shouted down, right?

      I'll tell you why: Because Google's JavaScript engine compiles any script it sees into machine code for your platform, then runs that... That's why you don't need a better option for security's sake than all or none... Machine code can't escape the sand box! (Realize the truth: There is no spoon^H^H^H^H^H sandbox.)

      The problem is that modern JS engines from all the major browsers do it this way -- The design of the JS language makes it hard to make a fast interpretor for it. Even if you pre-compile to byte-code and run it in a VM it's too slow.

      So instead, we take arbitrary data, compile that to machine code, then EXECUTE the compiled DATA (Data Execution Prevention, eh? Well, if it's flagging itself as executable, and it's accepting arbitrary code, I'd say that JS == Arbitrary remote code execution == one tiny step away from being an exploit anyway. I've always wondered why everyone disses ActiveX while enabling JS...

      PS. I've written scripting languages. They can be slow as hell, that's the point, so long as stuff you do a lot of is formalized and written in native code, it's all good and can be run in a pretty safe interpretor or byte-code VM.

      JS != general purpose compiled language.

      Therefore, when you do DUMB things like complain that JS can't keep up when you try to use JS + HTML5 Canvas as your "rendering engine" for a "web application" (or even worse, games) then browser devs must meet the dumb demands by doing the dumbest thing they can against their better judgment -- Just in Time compile a virtual EXE, then run that.

      The answer is to stop sacrificing security for speed, go back to software VM solutions with SIMPLE compiled languages like Lua, (I think, Lisp / Scheme too, not sure haven't checked how complex the sources are) and add standardized functions for commonly used features so we can get rid of the if(IE){...} cruft. Hint: Dynamic is the enemy of fast.

    2. Re:So... by lucian1900 · · Score: 2

      That's bullshit. JIT compilers increase the attack surface somewhat, but not significantly.

      Also, interpretation is always going to be slow. Lua is very slow without LuaJIT. So are most Scheme and Common Lisp implementations. Which is why no one in their right mind would turn of the JIT.

      A JIT may be harder to write than a bytecode interpreter, but it's not much harder to make secure

    3. Re:So... by StayFrosty · · Score: 2

      The extension you are looking for is called NotScripts.

      --
      "Frequently wrong, never in doubt."
  7. Re:I don't care about theoretical/researched explo by Anonymous Coward · · Score: 2

    True, but security researchers are not fighting the scattered guy in the basement who manages to find a hole.

    There are criminal organizations which are big enough to fund people in researching holes, as well as buying 0-days from the black market. Then using these either for a focused attack against a company, or cast it on the wind to gather up clients for a botnet. All is needed is a 0-day hole in a browser or browser add-on coupled with an exploit to get Administrator rights, paste this on the Web using ad rotation services, and it can easily bring in large numbers of compromised machines.

  8. What makes this extra awesome: Native Client by bl8n8r · · Score: 2

    This is the reason you don't want your browser able to access native OS code; when there's an exploit, the keys to the kingdom are in the browser.
    http://www.theregister.co.uk/2010/12/08/google_on_native_client/

    --
    boycott slashdot February 10th - 17th check out: altSlashdot.org
  9. Re:Keywords making all the difference by vajorie · · Score: 2

    So how is it a Chrome problem when the machine itself is vulnerable?

    The answer was in the few words before the ones you highlighted:

    bypass the browser's sandbox ... and run arbitrary code

  10. Why would the government care? by dicobalt · · Score: 5, Funny

    They run IE6.

  11. Re:Smug by flimflammer · · Score: 2

    That was pretty smug.

  12. Re:And.. by icebraining · · Score: 2, Interesting

    Chrome's sandbox is Windows' sandbox, so that's perfectly possible.

  13. Really? by petteyg359 · · Score: 2

    1. Watching the video, I see nothing that couldn't be achieved with ExtJS.

    2. Chrome often has multiple processes listed in task manager. In their video, they conveniently cover all those process names with another window so you can't see them.

    3. Suspicious overuse of "pwn". No company worth respecting would use "pwn" in a press release.

  14. How the exploit will be used by Hmmm2000 · · Score: 5, Interesting

    To me the most troubling part of this issue is what VUPEN does ... from their web site -- "Exclusive and sophisticated exploits for Law Enforcement Agencies". So, the reason the exploit is not being made public is so that Government agencies can use these exploits to install keyloggers or whatever they choose on whatever computer they which to target and monitor.

  15. Re:Good thing... by EoN604 · · Score: 2

    I always chuckle when I hear of people disabling JavaScript in this day and age. Reminds me of a guy from an old job who used to disable images in his broswer, saying they were unnecessary bloat that weren't important and shouldn't be a part of the web.

  16. Re:Pretentiousness by clang_jangle · · Score: 2

    Actually, the problem is so many people have no self-respect, and easily dismiss anyone who does as "smug". In fact, "smug" is one of the top insults routinely hurled about by people who feel inferior. They hope to "cut them down to size", "put them in their place", etc. If they believe they achieve it, they feel slightly less inferior for a minute or two. The failure, of course, is that no-one who matters really cares about all that drama. The "smug" accusers are nearly always trolls with nothing to offer anyway. It's a branch of the "shame and blame" control drama.

    --
    Caveat Utilitor
  17. Re:Good thing... by alostpacket · · Score: 2

    Good luck, I'm behind 7 Sandboxies.

    --
    PocketPermissions Android Permission Guide
  18. Re:And.. by black3d · · Score: 2

    I'm glad you put "possible" in italics to emphasise that this didn't necessarily mean it was the cause of the issue. Chrome implementing the sandbox, while overriding memory protection, kind of negates the purpose of the sandbox. (Although, it prevents "natively" bad stuff from affecting the system. However anything attacking the browser itself can still access system memory).

    To be fair though, the demonstration of this vulnerability has exposed nothing other than the ability to load known programs in known locations, without any additional parameters. They may be able to, but that hasn't been demonstrated, and won't be if they aren't releasing any "details".

    --
    "The true measure of a person is how they act when they know they won't get caught." - DSRilk
  19. Before everyone start yelling "fake" by Anne+Honime · · Score: 2

    A quick search turns out VUNET co-founder BEKRAR Chaouki was the winner of pwn2own 2011 : http://www.zdnet.com/blog/security/safarimacbook-first-to-fall-at-pwn2own-2011/8358

    Not to say it proves he did it again with chrome, but at least; the guy's got some credits for being able to pull this one.

  20. Re:Good thing... by stimpleton · · Score: 2

    7 sand *BOXXYS* ...fixed

    --

    In post Patriot Act America, the library books scan you.
  21. Re:Responsibility by dhavleak · · Score: 2

    Or they could do what Google's security researchers do when they find an issue in an MS product -- release the details to the world within 48 hours (those 48 hours being Saturday and Sunday).