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

Comments

Disclosure policy

[Anonymous Coward]

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

Re:Disclosure policy

[Anonymous Coward]

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.

Re:Disclosure policy

[EvanED]

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?

Re:Disclosure policy

[Rockoon]

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.

What about Google?

[d4fseeker]

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.

So...

[CrazyDuke]

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

[VortexCortex]

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.

Re:from vulpen site

[spongman]

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.

Why would the government care?

[dicobalt]

They run IE6.

How the exploit will be used

[Hmmm2000]

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.