Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Chrome Bug Google Security Windows IT

New Chrome Exploit Bypasses Sandbox, ASLR and DEP 150

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

This discussion has been archived. No new comments can be posted.

New Chrome Exploit Bypasses Sandbox, ASLR and DEP

Comments Filter:
  • Disclosure policy (Score:3, Insightful)

    by Anonymous Coward on Monday May 09, 2011 @04:51PM (#36076664)

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

    • by blair1q ( 305137 )

      Are you hiding your name from everyone, or are you sharing that only with /.'s government?

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

      They're always doing that and there's many companies like that. Basically, the bugs DO NOT GET FIXED until people (here, Google) pays up, and that's now the $5000 bounty we're talking about.
      These guys literally asks thousand hundreds. If not, well, bug stay there, bad advertisement for the company, etc.

      I know, people should get paid for their work, including the security researcH. But sometimes it feels like racket.

      • Google could pay one of their employees to track it down and fix it. If it would cost them $10,000 (opportunity cost, wages, extra time for code review or demonstrating correctness, whatever) to fix it or prevent it, then paying someone else $5,000 is a net win for them.
        • Yes, and no. It may be more expensive in the short term, but it will breed them their own class of security engineers who can then both track other bugs, and provide better design and coding guidelines to prevent future bugs.

          If a security firm, that presumably probes a variety of different softwares, can make a profit by asking 5k for a found vulnerability, then it's almost a given that in the long term you will be cheaper off with your own people watching fewer programs and having access to the actual code

          • by Lennie ( 16154 )

            Not only that, someone or more than one from Google or the community (it is an open source project afterall) has to look at the problem anyway, if only to see if there are other places that have similair problems.

        • Google DOES pay people to look for these bugs all day long, what are you thinking? Every big such company has a group or people that are paid to do just that. And another group of people reviewing the coder's work.
          If bugs were so easy to find, there wouldn't be any left by now. But that's often not the case.

      • I know, people should get paid for their work, including the security researcH. But sometimes it feels like racket.

        Why should they get paid if they weren't asked to do it? Obviously they don't have to say what they found if they aren't paid, but there shouldn't be a sense of entitlement just becuase the did something (that they weren't asked to do).

    • by mwvdlee ( 775178 )

      I call those "brown hat hackers"; trying to screw over computer users, while somehow still being legal.

  • What about Google? (Score:3, Informative)

    by d4fseeker ( 1896770 ) on Monday May 09, 2011 @04:56PM (#36076714)
    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.
    • by AHuxley ( 892839 )
      The NSA would like to see the world use more MS. If the world ever splits into local hardened operating systems with real on duty admins, field work gets more difficult.
      With MS in use/gifted at a state/federal level around the world, the US has their too kit in place. News like this shows what is been offered as finally 'safe' is really rather open.
      • Wow... so all of your friends and families have systems admins on-duty? I'm sure they also run every game they install or link they click on through security screening. Must get costly... must be very wealthy... think they might be ripe for some bank phishing...
      • I love a good conspiracy, but could you please explain NSA Linux [nsa.gov] then?

    • I think the folks at the Google Chrome developer team would like to speak to the VUPEN folks and find out exactly what's going on. This is because Chrome does incremental upgrades "in the background" and Google will quietly slip in update to the browser code to close these vulnerabilities without user intervention.

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

      While I understand the spirit in which your comment was written (and I happen to agree with you on this particular point), the NSA actually *does* have a mission to ensure US computer security. That's why they invested a hell of a lot of time in developing something like SELinux, which they open-sourced and donated, as well as providing substantial amounts of vulnerability research.

      I'm not saying that their intentions are always pure, but rather that they function as a sort of chaotic good. They're not re

  • Good thing I already run Chrome inside another sandbox (Sandboxie). Sure, there's been exploits for that sandbox, too, but it's uncommon enough that it's extraordinarily unlikely someone would combine the exploits needed. And I have a virus-scanner and firewall running behind all that, just for good measure.

    And even then I don't 100% trust it - any particularly suspicious sites are accessed by ssh-ing into my OpenBSD box (with it's own virus-scanner and custom PF rules), then running Firefox (with Javascri
    • by Anonymous Coward

      So long as you don't forget to properly affix your tinfoil hat, I'd say you're good to go!

    • by Anonymous Coward

      You're a belt and suspenders kind of guy, aren't you?

    • I can crack that easily, and get at your data. You forgot rubber hose hacking...

    • by Anonymous Coward
      Last I checked Sandboxie was an IO-layer sandbox; a kernel or os/service exploit would skip right over your sandbox without even noticing its presence.
    • by EoN604 ( 909459 )
      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.
      • Thing is, I wouldn't /like/ to have to disable JS, or run NoScript, but thanks to poor implementations of ad code, disabling it can /seriously/ speed up loading on a high(ish) latency connection.
        And that's on top of all the potential attack vectors.

        Speaking of which, /. runs /much/ faster on my phone when you disable JS - None of this slow ajax and hugely-long page to re-render when you add a comment.

        • I use Noscript on websites until I've determined I need the scripts. Its easy enough to enable them once I'm there, and much much faster to load complex websites without it.

      • Actually, I really disabled it because it's running on an Athlon 900 with 384MB of RAM. The security advantage is a side-benefit.
        • by Nutria ( 679911 )

          it's running on an Athlon 900

          Why?

          It's not old enough to be Retro, yet not fast enough to run a GUI is 2011.

          • Because that was what was in my spare box. Seriously, the machine's cobbled together from salvage - a CPU/mobo from one machine, a video card from another (GeForce 2, not that it actually accelerates anything), RAM from two different sources, hard drives from three, and miscellaneous CD drives and floppy drives, just because. And the software is equally... Frankensteinian. Samba, Apache, MySQL, a full X desktop (it's my backup backup ordinary-use computer), FTPD, a couple other things I've forgotten, and Do
    • Good luck, I'm behind 7 Sandboxies.
    • by mlts ( 1038732 ) *

      Never say never. I recall reading some malware can detect the presence of vmware and/or sandboxie and get around it. Sandboxie helps, but it of limited protection on 64 bit systems.

  • by Anonymous Coward
    I am so glad I run [insert smug zealous OS plug here] and not Windows!
    • Bull GCOS 7 would never have these kinds of vulnerabilities.
    • 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.
      • That was pretty smug.

      • "The problem with being better than everyone is that people tend to think you're pretentious."
        • 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
  • that enable them to bypass the browser's sandbox, as well as ASLR and DEP, and run arbitrary code on a vulnerable machine.

    "...on a vulnerable machine...". Those are the keywords. So how is it a Chrome problem when the machine itself is vulnerable?

    By the way, it was about time for /. to embed video. Please allow the same for pictures especially for slashdotters here.

    • 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

  • by Anonymous Coward

    This "VUPEN security" company, how are they any different from HBGary? They sold 0days to governments too...

    I just want the damn hole closed.

  • by JonySuede ( 1908576 ) on Monday May 09, 2011 @05:13PM (#36076908) Journal

    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

  • by magamiako1 ( 1026318 ) on Monday May 09, 2011 @05:16PM (#36076926)
    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.
  • by CrazyDuke ( 529195 ) on Monday May 09, 2011 @05:27PM (#36077012)

    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?

    • Re:So... (Score:5, Insightful)

      by VortexCortex ( 1117377 ) <VortexCortex@[ ] ... m ['pro' in gap]> on Monday May 09, 2011 @06:48PM (#36077716)

      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.

      • 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

    • The extension you are looking for is called NotScripts. [google.com]

  • by bl8n8r ( 649187 ) on Monday May 09, 2011 @05:28PM (#36077032)
    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/
    • by Anonymous Coward

      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/

      Native Client doesn't allow access to native OS code; it allows a restricted set of machine instructions to run in an environment that is not only heavily sandboxed, but verified pre-execution. Because it's meant to be cross-platform, it does not allow calls to the underlying OS at all. It enforces this limitation by doing a code scan to detect unauthorized instructions, unsafe branch targets, and such. It's really quite sophisticated, albeit practically unusable due to how locked down it is.

      It'd be daft to

  • Okay, I've watched the Video twice, and read both linked articles (yeah I did) and it said that it was ..

    The video shows the exploit in action with Google Chrome v11.0.696.65 on Microsoft Windows 7 SP1 (x64). The user is tricked into visiting a specially crafted web page hosting the exploit which will execute various payloads to ultimately download the Calculator from a remote location and launch it outside the sandbox at Medium integrity level.

    Well I did see the Calculator applet get started, and I do see

    • Umm... who the hell cares? If you can launch a Medium IL process, then you're out of the sandbox and can launch *any* medium IL process, even if it's from \WIndows\System32\ on the local box. For example, you could instead launch
      \Windows\System32\cmd.exe /C "ftp myexploitsite.com/payload.exe" && payload.exe
      Commands simplified for readability, but you can do this. You probably won't have Admin, but you can still do a lot of damage - and if the user is one of those idiots who decided that UAC is too m

  • by dicobalt ( 1536225 ) on Monday May 09, 2011 @05:34PM (#36077064)
    They run IE6.
  • 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.

    • Errr, perhaps you missed where they apparently had the browser start the windows calculator executable. That's a fairly fundamental ownage right there.

      • by EdIII ( 1114411 )

        Ok. I can schedule a task from the command line to run the calculator app. Not only that, but custom event filters that trigger it, it would be possible to get a modified Google Chrome itself to cause the calculator to open.

        His point is that they seem to be hiding something with the process window being obscured and yours is the simple fact the calculator pops up without actually running the calculator app (which could be bound to a hot-key you did not see pressed to btw) and therefore provides some credi

    • In process explorer, the calc.exe is only indented far enough to be a child of explorer.exe, not chrome.exe. So surely calc.exe was launched from explorer, not chrome?

  • by Hmmm2000 ( 1146723 ) on Monday May 09, 2011 @06:04PM (#36077322)
    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.
    • by Anonymous Coward

      What kind of professional research firm for Law Enforcement uses the "word" "Pwned" in a press release?

    • by EdIII ( 1114411 )

      Then why advertise it in a press release?

      That would be like me constructing a dirty bomb the size of a suitcase, undetectable by everything including the TSA, and then taking out an advertisement in the New York times announcing it exists, but only available to be auctioned to qualified really-super-scary terrorists.

      You advertise a bug like this obscuring the results when you want to COOPERATE with the open/closed source programming community to both do the right thing and to gain credentials that your comp

      • by tlhIngan ( 30335 )

        Well, I suppose they're "saving" it for Pwn2Own. But given CanSecWest happened recently, they're also doing a CYA - if it gets revealed how it works, they've already scooped the story.

        So it's a win-win. Either an easy victory to win that Windows laptop (sure it ain't a shiny Macbook that everyone else is going for... but it's also less competition), plus lots of money from those interested, and credit should someone else happen to discover the same bug.

  • by Anne Honime ( 828246 ) on Monday May 09, 2011 @07:55PM (#36078162)
    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 [zdnet.com]

    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.
  • If you look closely, the first time the video shows process explorer, the PID of the parent chrome process is 1388 with integrity at "Medium", and a child chrome process's PID is 1928 with integrity set at "Low". After the hack, process explorer shows a child chrome process with PID 804 and integrity "Medium", all other processes except for the calculator are obscured. I can guess-timate that the original parent and child are still there though, as there is still a low integrity process somewhat near the
    • Or maybe the gray colored process line is just the last selected process, which makes way more sense.
      • correct, suspended processes have a darker gray background. the light gray is the selection highlight for inactive windows.

        it's somewhat suspicious, though, that the un-maximized chrome window is set up to obscure all but the new medium-trust chrome.exe and calc.exe.

        it looks to me like they've done some heap spraying in chrome.exe (see the unusual 450MB working set).

        the list of 'gray' processes in the 2nd procexp session are:
        1) explorer.exe
        2) process_explorer.exe
        3) process_explorer64.exe
        4) chrome.exe (UI)
        5)

  • Since they aren’t informing the Vendor so it can get patched,
    Are they going to take responsibility when it does get into the wild?
    Oh, we‘re big security company, we’re secure!
      Yeah right!
    Show me a boat that doesn’t leak!

    • 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).
  • That video shows exactly nothing - any 2 screen system can do Windows-R + "calc" offscreen and lob it into the picture, whilst it's looking at a web page. You can also not see if it really is a sub-process, that part is obscured. As far as I can judge by the indentation it is NOT a sub process - thus no hack. But I'm no expert - unlike them I won't pretend to be one either. In summary, this *seriously* lacks credibility.

    It's IMHO a rather stupid attempt at getting their name out the and lick up to Frenc

  • To be done right a sandbox must either be implimented with hardware (max priveledge required) or be an interpreter that mimics (virtual) that setup. The best place for a sandbox is in the OS itself- something windows doesn't do. Without that you are a single buffer overflow or improperly passed pointer away from a compromised system.

One half large intestine = 1 Semicolon

Working...