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."
Disclosure policy (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!
Re:Disclosure policy (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.
Re:from vulpen site (Score:5, 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.
Re:So... (Score:5, 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.