Sergey Glazunov - Full Chrome Pwn win $60,000

https://pwnium.appspot.com/


No details yet - probably won't be for a while after the patch is released so that people can update.

Pretty impressive.

The 60k prize is reserved for Chrome-Code-Only exploits that leave persistent code on the host.

There were 2 exploits used to accomplish this - likely one to drop the code and one to execute it outside of the sandbox.

 

Thanks for the info. This only shows it's always playing catch, and that nothing is 100% effective.

This is one of the reasons why I use full low integrity level; not to mention redirect modifications.

I hope they will soon release information about it; I'm dying to know what it was.


Thanks!

 

Full low integrity would only matter if it had been exploited through the broker process. If they just flat out exploited a low integrity tab, or renderer, or gpu process then there isn't much to do about it except patch.

The nice thing about the sandbox is that it takes two vulnerabilities to leave persistent malware, which means the cost of an exploit is much larger.

 

Hi,

I would be willing to bet that one of the two exploits is against the Chrome SQLite profile. About a month or so ago one of my sandboxes caught an unusual write to the Chrome profile.

The exploit was almost successful. The only problem was that I had multiple Chromium installations on the sandbox and the exploit was writing to the wrong profile. The exploit was successfully modifying the the %USERPROFILE%\%APPDATA%\Chromium\* profile path... but I was running a special build of Chromium that stored the profile locally... not at that location.

The parent chrome process is what loads the user profile. This would make perfect sense for escaping the sandbox... the *first* Chrome process is running with the rights of the user. Its only the child processes that are running sandboxed and under low integrity level.

Unfortunately I caught the filesystem change a few days too late and was unable to perform a forensic analysis on the packet capture logs because they were rolled over so I missed the stage-1 exploit and only have the 2nd.

Best Wishes,
-MessageBoxA

 

Interesting that you say that ,but I always understood, and due to what's mentioned in Chromium's sandbox documentation, that Chromium's browser process can mitigate the damage that an exploited rendering engine can do.

The browser process is the broker process or the parent process. The rendering engine is the render process or renderer.

In a normal configuration, Chrome's sandbox (the integrity levels part) would either be Medium (broker process) <> Low (render process) or High (broker process) <> Low (render process)

This means that, in the eventuality of an exploit to one of the render processes, that in Vista/7/8 would also be running @ low integrity level, then it would be harder for the malicious code to do severe damage. It would only be able to write to low integrity level containers, which are very few.

This means that, in order to do more damage, in case of Vista/7/8, then it would need to also break from low to medium/high.

Of course, this should always be patched. But, when running with an explicit low integrity level, you're effectively restricting what the malicious code can do, and even make it do nothing, at all, which is why also made a reference to not to mention redirect modifications.

I'm not saying or trying to imply that you're wrong; I'm just saying what I knew from reading from the documentation about the sandbox. Are you familiar with some other documentation that goes further into it?

 

Thank you for sharing this information.

Very interesting. In my configuration, due to the broker process being @ low integrity level, and that my profiles have a medium integrity level with NoWriteUp and NoExecuteUp, then nothing can write to there.

I like this approach.

-edit-

Not to mention that %localappdata%\Local\Temp is @ medium, and therefore only an exploit resulting in malicious code running in memory would be successful. Of course, I'm excluding an eventual kernel exploit. lol

 

According to this, it didn't break out of the sandbox, it actually avoided the sandbox and was able to run with the user's full permissions*: -http://www.h-online.com/security/news/item/Chrome-hackers-strike-Pwnium-1466270.html

* Won't this involve the integrity levels as well? If the rendering engine, which is @ low, does not run with the same set of permissions of the user, then it means it had to be able to go medium/high to get the same amount of privileges of the user.

Also: -https://www.zdnet.com/blog/security/cansecwest-pwnium-google-chrome-hacked-with-sandbox-bypass/10563

Apparently, VUPEN also broke the sandbox:

-http://www.h-online.com/security/news/item/Chrome-hackers-strike-Pwnium-1466270.html

 

Any idea why this distinction:
"Pwn2Own, however, requires contestants to disclose code execution bugs, but not any sandbox escape exploits."

 

Not sure Vasa, where do you read that? It seems that both were disclosed and both were patched: https://pwnium.appspot.com/

@Moon,

There's been a design flaw in the sandbox for a while - that's how Vupen bypassed it last time (Flash exploit + Sandbox design flaw.)

It really depends on what the flaw is. If there's access that the broker has that Chrome doesn't need, lowering integrity would potentially mitigate the risk.

If it's a limitation on the integrity system itself, that's another story.

BTW the patch is out:
http://googlechromereleases.blogspot.com/2012/03/chrome-stable-channel-update.html

 

I know that. It went from low to high. It need to get permissions it would lack otherwise. Which is precisely the reason I mentioned why I run full low.

But, what you answered here is not an answer to my question. You said one wouldn't need to get from low to medium/high; all it would require would be to exploit a low tab. How? The broker is there to prevent damage that an exploit low tab (= render process) can do (as we know, not 100% effective, but nothing is). The only way would be to go from low to medium/high.

Anyway, when more details come out, we'll know more. Most likely they're already out, considering there's an update already? I'll have to check. I'm interested in reading more about it. lol

I agree with that.

Don't know... or it could be a flaw in the way Google Chrome makes use of it. If it was a limitation in MIC itself, then considering that security bugs are present in software all the time, then it would also affect Internet Explorer and Adobe Reader X. So, I got my doubts it's MIC. Just how Google Chrome uses it.

We cannot forget that for the sake of convenience, there's interaction between the low and medium/high processes in Chrome's sandbox (Just like in Protected Mode.). There's also actually a brief moment when we start Google Chrome that the render processes actually start with medium/high to get enough access to things they will need.

This is what I took away from Chromium; I removed this convenience and interaction between low and medium/high, as they're all low.

Anyway, even in a standard Google Chrome installation, anyone educated enough would probably have something like a default-deny, etc. So... the real problem are all those other folks who aren't educated in these matters.

Thanks for the heads up!

 

I was probably unclear - this isn't what I meant. You need to do more than exploit the low integrity tab, you still need to make use of the design flaw.

Design flaws have come up in the past (from Sergey) and he's noted that they are pretty difficult to find. So I wouldn't be too worried about hackers going after Chrome just yet =p

 

Sorry! Last para here: http://www.computerworld.com/s/article/9225010/Chrome_succumbs_to_Pwn2Own_contest_hack

 

I see. They probably make the distinction because of how valuable those exploits are - people won't give up a sandbox bypassing vulnerability for just a few thousand dollars unless they're really committed to helping the project.

 

So what Vupen found may remain unpatched. Or, since they haven't detailed their activity, Google can't claim to have patched their exploit.

 

Yes, it may remain unpatched. Really impossible to say, for all we know that same exploit was just patched because of Sergey - though I personally doubt that.

 

I wonder who are the main clients of those companies . . . governments? Sheeesh

 

Yes, primarily governments.

 

Is there any confirmation on that?

 

http://www.vupen.com/english/services/ba-gov.php

It's what they market themselves as.

 

Thanks! Their services would require quite deep access to all sorts of things! I wonder which governments would risk giving them access. If these guys turn rogue, NATO etc could end up severely compromised.

 

And again,

Teenager hacks Google Chrome with three 0day vulnerabilities
hxxp://www.zdnet.com/blog/security/teenager-hacks-google-chrome-with-three-0day-vulnerabilities/10649

Also, about the Pwn2Own exploit,
How Google set a trap for Pwn2Own exploit team
hxxp://www.zdnet.com/blog/security/how-google-set-a-trap-for-pwn2own-exploit-team/10641

 

Interesting read. I fully read both links

 

Haha, funny that they dropped that for flash exploits. Not that it matters - the only exploits in Chrome that I care about are the ones that break out, whether they jump in with a flash or chrome exploit isn't nearly as important.

That said, the Flash sandbox is weaker than the renderer sandbox so that's something.

It also means that it is far less likely that this exploit would work with PPAPI Flash. That's important, especially since Linux defaults to PPAPI.

 

Already a patch incoming, now that's pretty quick.
http://omahaproxy.appspot.com/viewer

 

“I got lucky because I found a way [to jump out of the sandbox] very early. I figured it out by looking at it carefully,” he added.

There's an initial moment when the renderer processes have the same privileges has the broker process. I wonder if this is what he took advantage of? I guess we'll know more as soon as the new version is distributed.

I'm glad Google started their own contest. This way they get full rights of the exploits and get to do something about it, without having to guess.