Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass

Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass
[FONT=Verdana,sans-serif][/FONT][FONT=Verdana,sans-serif]
We are (un)happy to announce that we have officially Pwnd Google Chrome and its sandbox.

The exploit shown in this video is one of the most sophisticated codes we have seen and created so far as it bypasses all security features including ASLR/DEP/Sandbox, it is silent (no crash after executing the payload), it relies on undisclosed (0day) vulnerabilities discovered by VUPEN and it works on all Windows systems (32-bit and x64).[/FONT]


More Info:- --http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php--

 

No PoC available publically available? Only for paying customers? Not really liking that...

 

I wonder if it has something to do with this https://www.wilderssecurity.com/showthread.php?p=1858831#post1858831

Read from that post afterwards.

 

More news about it -http://krebsonsecurity.com/2011/05/security-group-claims-to-have-subverted-google-chromes-sandbox/

Anyway, whether or not this is something different, there's a reason why I run Chromium with an explicit low integrity level - nothing breaks out of the sandbox. There's no medium integrity level to inherit.

 

Damn clever, whichever way you look at it ! Just shows that even with ALL those obstacles in the way, nasty stuff can still intrude

Government customers What, like "you know who" LOL. Wonder how much they pay for exploits such as those, and how often they use them ?

EDIT

Sho nuff

 

I had it happen multiple times the other day when testing a bunch of zones settings. It was with the latest chrome, and it happened maybe 6 times that I noticed. I personally don't believe it to be a flaw with ProcessExplorer.

I found some oddity in it though. At times, just opening a new tab will cause that specific chrome job to be at a medium IL instead of low like it should be. The other day I was messing with downloads and the zones, so I was testing settings then downloading and executing different things. anyway, I noticed a few times that when I executed something with chrome, it was running at medium instead of low. That is, the file executed at medium. So it is no wonder if a hacker can make this flaw happen at will that he could execute something at a higher level than should be allowed.

Sul.

 

I also believe it has nothing to do with Process Explorer.

What raised my suspicions was the way I got answered by Chromium/Chrome developers. Somehow I got the impression they wanted to avoid the discussion around it.

It's just way too much of a coincidence for this not to be the same issue.

But, the VUPEN info does bring an opportunity to strike back.

This is a reckless behavior by Google, if you ask me.

 

Wouldn't that be chromium rather than google? I have seen it in both. Or is chromium and google the same backbone with a different front? Erm, I mean does google take blame for chromium as well as chrome?

Sul.

 

When you consider that chrome sandbox is based on

a) assiging restricted token (to reduce rights)
b) assiging job object (to close user handles gap)
c) assiging alternative desktop (to close services messaging gap)

And process explorer is polling the status, according to the chromium developers PE polls tabA, while tabB is being created. TabB is created so fast that the poller mechanism somehow captures the status of TabA (the one with medium rights), but errorfull assigns this status to the proces ID of tabB (the one just created).

It seems plausible, but when considering that 100,000 to 200.000 cycles easlily go into a CPU processing second of a reasonable powered dual - quad core. Sully, Moonblood and I were incredible lucky to draw this window of opportunity several times in a few days. With so many cycles in a CPU second and Process Explorer needing the luck to poll at the right moment (to make an assigning mistake itself), I just don't believe that explanation. Well back to IL (low rights mandatory again)

 

A default-deny execute system should prevent a payload from being executed like in a Standard account + SRP, should it not?


I suppose I should get started on giving low integrity a try via Sullys post here

https://www.wilderssecurity.com/showpost.php?p=1760740&postcount=5

 

Looks like Sandboxie isn't redundant after all (and never was, especially after applying restrictions).

 

Wink, wink!

That's why it's so interesting to read about how people are surfing without this or that protection. (I don't use NoScript.)

Incidentally, this VUPEN has also shown exquisite timing in releasing its news. I wonder which government agency will be stupid enough to pay to find out about the exploit only to have Google fix it in a week or so. And isn't Chrome *not* really the favorite of most US government agencies?

 

all this talk of icalcs and setting Integrity Levels seem a little complicated to me.
although i think i could manage given the time...

i think i'm just gonna switch to IE9 and call it fixed!
beside, i found Mouse Gesture for IE and Speckie which makes switching to IE9 more pleasing.

 

Considering that this is a buffer overflow attack I assume using a separate security method that protects against it would render the attack pretty useless?

Comodo's Defense+ has buffer overflow protection.

I think this really isn't something to worry about though. A single instance of their security being broken in 3 years is a damn good track record.

Your browser shouldn't be your first line of defense nor should it be your last anyway.

 

It has more vulnerabilities found though.

 

this could afford a little extra protection to Chrome:

i like that!

 

Installing in program files would be a bad idea, wouldn't it? Isn't the whole reason they don't install there for security since program files need admin rights.

 

Not all applications from Program Files need admin rights to function. Chrome is one of them.

 

No, all programs should install in program files where they are supposed to. But any form of configuration file or files that are frequently modified should NOT be installed there.. that's up to the author to make sure their program installs in the proper locations.

 

Exactly. You want the program and dependencies located in a directory off limits to users, keeps the tampering down. To update though, it might pose an issue because you would have to start the browser as Admin for it to auto-update - or UAC would have to kick in somewhere.

You want the settings and configurations and temp/cache in the users profile. This allows the user to change "settings" all they want.

Sul.

 

-http://www.geek.com/articles/chips/webgl-flaws-puts-chrome-and-firefox-users-at-serious-risk-2011059/

 

I see a lot of people moaning that IE9 doesn't support WebGL, I also see a lot of people thanking them because of security issues that apparently have been discussed time and again revolving around WebGL. Reading some links this isn't the first time security issues have appeared about WebGL. I'll stick with D2/3D right now.

 

It's possible to disable WebGL support in Google Chrome. You need to place this flag in your shortcut --disable-webgl.

 

FYI dont know if its a fp or not, but Avast popped up saying it blocked an exploit when just visiting this link.

[IMG=http://img24.imageshack.us/img24/9109/avasty.png][/IMG]

 

That's not an FP. Do you use an adblocker? I think you were just subject to a PDF drive by attack.