Sergey Glazunov - Full Chrome Pwn win $60,000

Details don't come out for like... a month for patches like this - that way everyone is up to date by the time exploit info is out.

Me too.

I just wish MS allowed for a more robust sandbox.

I would be really surprised to see this happen on a Chrome running on Linux using the various sandboxes available. Enabling seccomp sandbox and making use of a hardened SELinux sandbox on top of the default chroot is going to absolutely break exploits. It's tempting to switch just because of how much I like seccomp lol

 

Wouldn't that be the same as saying, I'd like to see it happening in a Windows system using an explicit low integrity level + what else? For some reason I can't stop thinking that none of these exploits against Google Chrome would prevail in my system. No need for Linux, at all.

If we're going to talk about non-standard configurations - something Jane and Joe could do -, then the only thing I'm concerned about is a kernel exploit.

But, in that case, wouldn't Linux also be susceptible to such?

If we're talking about standard configurations, then according to this:

Source: -https://www.zdnet.com/blog/security/pwn2own-2012-ie-9-hacked-with-two-0day-vulnerabilities/10621

I suppose that includes Linux as well.

 

Patch out:
http://googlechromereleases.blogspot.com/2012/03/chrome-stable-update_10.html

 

I would not be so sure that running the broker as low integrity is all it takes to stop these. It's entirely possible though.

The reason I'd like to see it in Linux is because there is incredibly finely grained access control down to whitelisting specific calls to the kernel that Chrome can make as well as running in separate file systems with 0 rights etc. You can't get that on Windows - Chrome comes sorta close with the virtual desktop renderer.

Not necessarily. There are still kernel exploits, of course, but it's not always possible to get far enough to exploit them.

Possibly - it could be OSX and Windows since those are usually the two tested in pwn2own. Either way, the seccomp sandbox is not enabled by default in Linux.

 

I didn't mentioned only integrity levels. I mentioned integrity levels + something more. (I actually mentioned + what else. But, same deal.)

This something more can be modifications redirection, etc. You're not limited to integrity levels in Windows. But, even with just integrity levels, you can actually make any exploit running in low integrity level nule.

There's only a couple areas to where objects running @ low integrity level can write to. Which is why, in theory, with the default sandbox, the broker process would prevent writing to higher locations. But, due to design flaws, as we can see, sometimes it doesn't work as expected. But even then, depending on your needs, you can prevent a low integrity level object from writing to those areas.

Even if you need to allow writing to those couple locations, you can still block execution.

But, if you apply an explicit low integrity level, then anything will inherit the broker process permissions... or lack of. The only thing that would happen is that a low integrity level object can still read from objects with higher integrity levels. You can blind them, though.

MIC is an underrated security mechanism, even by Microsoft.

I suppose you're talking about AppArmor? It would be nice to have that, I don't deny. But, does it mean Windows is any weaker?

Then again, you have third-party alternatives to that, which allow the same kind of control (or practically the same). So, again... is not for lack of choices.

But, it is possible, right?

The same with Windows. Just because there's kernel exploit out there, it doesn't mean it will succeed. It may happen that it needs to read something that, for instance, Internet Explorer Protected Mode or Google Chrome sandbox denies reading access...

It could be a lot of things...

 

Apparmor, SELinux, CHROOT, and Seccomp are all sandboxing modules that I'm referring to when I talk about the linux sandbox.

Third party choices are not ideal. Introducing more and more attack surface will overcomplicate the model and can even lead to a bypass earlier on.

Possible, yes. It's just the fact that on Linux I can stop Chrome from using any API call except what it's designed to use, I can stop it from interacting with literally any file, I can stop different types of IP, I can force it into a separate file system, etc. With windows I can apply some generic file system restrictions.

So can exploits still happen in Chrome on Linux making use of SELinux, AppArmor, Chroot, and Seccomp? Yeah... anything's possible...

The idea of things like ASLR, DEP, Sandboxing etc is primarily to drive up the cost of a single exploit and to force the attacker to play by your rules. On Linux you can define a very very short list of things the attacker can do, on Windows you can't. It's just a matter of making things much more difficult for the attacker.

It's mostly just academic - will you be safe from Chrome exploits on Windows? Yeah, probably. So does it matter that you would be "extra-safe" on Linux? That's up to the user. But that's pretty much the definition of defense in depth.

 

So can exploits still happen in Chrome on Windows making use of explicit low integrity level* + redirections* + restrictions* + what ever else**? Yeah... anything's possible...

* All native stuff, by the way. ** It could or not be native stuff.

Sorry for copycatting most of your sentence!

I agree that AppArmor, SELinux, etc do provide a bit more control over what a specific program can access. I won't deny that. But, you can also isolate dangerous applications in Windows, restricting what they can access as well. And, this is what it's all about - restricting the most dangerous applications.

As I previously mentioned in one of my posts, there's only a couple of locations to where my profiles can get write access to. The areas I deem important, they're actually 100% blind to them; they (the profiles) can't even see them. So, in a way, I can achieve the same and using only Windows MIC.

As I also previously mentioned, Windows Vista/7/8 MIC is one very underrated Windows security mechanism, even by Microsoft.

 

They provide almost complete control. The fine-grained ability to control is what's so nice. Can you run Java as a low integrity application on Windows? Nope. There's nowhere between LI and MI. On Linux I can run (for clarity's sake, even if it doesnt make sense) Java as a "medium integrity" process, but then restrict things down so that even if it's not all the way "low integrity" it's still seriously reduced.

That's just not something you can get with Windows.

MIC is great. It's "pretty good" security and it makes targets hard enough that real-world hackers will attack something that doesn' tmake use of it. But if we're going by an academic defense in depth standpoint it's always a good idea to restrict programs as much as possible.

 

I said I don't deny that. But, I can have it to an extent. And, to be honest... it allows me to do what I want - restrict dangerous applications, so that they cannot harm my system. Anything beyond that... it's what I call extra comfort.

That's a bold statement. You actually can. I told you in the other thread to search for user MrBrian posts about it. Well, I didn't say it in a direct way, but I did say he tested Java in low integrity level. I mentioned there was some issue, but I didn't recall if it was related to integrity levels.

So, saying one can't run Java @ low integrity level, it's simply not true. Have you actually tried it yourself to make such an affirmation?

Even if one couldn't run Java @ low integrity level, one can still reduce malicious activity as well in Windows. I'm truly not getting it...

Actually, that's just plain wrong. If you actually bother reading what I've mentioned so far, about all you can do using native Windows security mechanisms, you'd see that affirmation is wrong.

I agree with that.

This is where the line actually starts to get drawn. There's a difference between restricting dangerous apps - which you can do in Windows - and enjoying the extra comfort.

 

Really? Running Java at low integrity completely broke it for me - both when I tried running the Java .exe as low and when tryin gto run Chrome as low. Perhaps there's a workaround.

Regarldess, the point is that if an application doesn't fit into low integrity you're stuck at medium. You can't really get between the two levels. I can think of plenty of internet facing applications that could be potentially exploited (torrent clients, downloading clients, firefox, silverlight) and won't "fit" into the confinements of low integrity - on linux they wouldn't have to.

How? How can you restrict file access to a specific file/ folder without dropping down an entire integrity level, potentially breaking the application?

I agree. This is what I was saying in the last post - you can still get a nice level of security in windows just by using the integrity system. But not every application is goin to be able to drop down into low integrity.

Integrity is like... "less privileges" and SELinux/Apparmor are like "least privilege."

 

You make it sound like MIC is the only thing Windows has. You actually don't have to use MIC to force a low integrity level on dangerous applications to restrict their actions - this is actually what I call extra comfort.

Using Chromium with a low integrity level is an extra comfort I got. Yep, Windows also has extra comforts.

It's actually funny that you mention it. There are in between integrity levels. I just don't know how they play. There's lack of documentation. The only documentation is a Microsoft support page that mentions them and also a MSDN page that only makes a brief mention. So, I don't know what one could do with them.
I need to dig deeper to learn more about what could be achieved with them.

But, even if one can't have middle integrity level between low and medium, that's not the only thing you can use to restrict actions.

And again, you're making it sound like MIC is the only thing Windows has. It's not.

And you're still making it sound like Windows users have nothing more to use but MIC. Even in the eventuality an explicit low integrity level breaks something, you're not restricted to using MIC. You need to think outside of the box. Once you think, you'll know you can do it.

 

There are lot of integrity levels with various weird IDs, but there are only 6 that are documented in any way. There could be 100 integrity levels, but you're ilmited to 100 "profiles" for applications to run in.

Other than integrity what methods of restriction a programs file access are there?

 

Oh please, if there were only 1.000.000.000 integrity levels, I'd still be limited by them. What's really the point you're trying to make?

I told you to think outside of the box. There was actually a thread sometime ago about this, started by another user, and where you lurked around. But, let me quote something I mentioned in one of my posts, in this Sergey Glazunov thread:

So can exploits still happen in Chrome on Windows making use of explicit low integrity level* + redirections* + restrictions* + what ever else**? Yeah... anything's possible...

* All native stuff, by the way. ** It could or not be native stuff.

And, to be honest, for someone who claims integrity levels (Windows MIC) limit a lot what one can achieve, surprisingly enough I can run Chromium/Chrome @ full low integrity level, which on its own would restrict 99,99% of threats, because it cannot interact with any of my other operating system vital locations, while you seem to be having a great deal of difficulties of having an AppArmor profile around your main Chromium process, because apparently it's breaking the browser?

Source: https://www.wilderssecurity.com/showthread.php?&t=320017&page=2

So, apparently, AppArmor profiles also break functionality. At least, I can say with 100% satisfaction that a full low integrity level won't break Google Chrome or Chromium in Windows.

And, you could then come and claim that even without an AppArmor profile around the browser's process, that you still have everything else; but, guess what, even without an explicit low integrity level, I still have everything else in Windows as well. All you got to know is how to make use of things to work in your favor.

 

The point I'm making is that on linux you get a sandbox that's completely attuned to the application, not a generic one that's either a bit to big or a bit too small. Chrome's renderer process could probably be run with even fewer rights if there were some way to get it in Windows, but there isn't. You could run it at untrusted integrity, but that's probably too small and would break it - on Linux if you use the seccomp sandbox the renderer (and every other process) is limited down to the specific calls that each can make.

In my case it's a bug - probably two conflicting profiles (I have an AppArmor profile already on the renderer, I still suspect that that's the issue.)

As you can see in that topic another user has the profile working and Chromium is restricted by AppArmor.

I mean, yeah, Linux can be buggy. Especially when dealing with security. When testing out integrity levels on Windows I had plenty of programs stop functioning entirely.

I still don't see what other methods you have in Windows to restrict an application. Redirection? Is that something like a symlink? And what other restrictions can you apply to an application that isnt based in the MIC?

And to reiterate, the only point I'm making is that on Linux you can have a much more fine-grained sandbox than on Windows. You can argue that it doesn't matter and that low integrity restricts enough but I don't see that.

If Chrome on Windows were restrcted from making specific calls it didn't need and had completely restricted file access we probably still would have seen Vupen own it, they're a security research team that has multiple people trying to hack things for weeks, but they went after the Flash sandbox for a reason - the more restrictive the sandbox the longer it's going to take to hack. Flash only runs as low integrity. Had Vupen gone for an exploit in the renderer sandbox it would have been much more difficult - possible, but more difficult. And if they were attacking a sandbox equivelant to how Linux does it (completely refined sandbox that restricts ipc, individual calls, and file system access), even moreso - we might have seen another year with Chrome going by unscathed.

 

What I don't like about this ordeal...and I can tell you guys feel it too: VUPEN left a few hints about this exploit and that's about it.

That leaves the standard sec-head thinking:

Am I still vulnerable?

Would my "flash OD" "low integ" "granular sandbox" or "script policy" etc etc fix this

I'm thinking this is exactly the buzz VUPEN wanted to create. Because remember one important facet of grey security. Purchase to cease. If these guys chalk enough talk time among the Google security and PR teams--they'll just buy it.

I'm also thinking this revolves around the medium integrity processes that I too can recreate but the MIT/Stanford grads at Goog can not.

 

Well, we know that they used a Flash vulnerability and broke out of the Flash sandbox. Using the PPAPI Flash plugin should completely mitigate their particular exploit. As for the other exploits that surely lurk just waiting to be discovered, there isn't much to do. You can try running the entire process as low integrity... but it's impossible to say if that would help given that we know nothing about the potential exploits.

Slap every restriction you can on every application you can, that's the best defence imo.

 

Which of course can present its own problem. It took me a bit to remember, but then the name Vupen hit me..these are the same guys we talked about months ago that claimed they broke Chrome, but kept the info hidden away. Looks like they weren't just blowing smoke after all.

We just have to do the best we can, no matter what application or browser we use. No matter what Google, Microsoft or anyone else throws at the hacker problem, hackers and the malware they create will eventually get around it or go right through it regardless, if the target is big/popular enough.

 

It was a Flash exploit last time as well, possibly the same one.

The thing is, you can secure Chrome all you like... the hackers will just go for Flash... and Google can secure Flash all they like but the hacker swill go to Java etc etc etc. And maybe one day all applications will run in a nice low integrity isolated process and they'll support ASLR and DEP and all of hte latest mitigations and we'll either see a rise in kernel exploits or a rise in socially engineered malware.

And I've completely forgotten what my point was.

 

Yep, completely agree (on everything besides what your point was supposed to be, lol..that I don't know.) Social malware is already a hot business, all thanks to social media and the latest mitigations, imo. Though I haven't followed or dealt with Win 8 in a serious way yet, I'm quite willing to put money on it already being on a digital operating table with hackers gathered around it, poking it.

Heck, I'd even be comfortable betting that somewhere in the world, a group of guys or some kid is just sitting on an already found vulnerability/vulnerabilities, waiting for a better moment to pounce. Things just aren't going to be that different, they never are.

 

POC malware has been out out for Win8 since week 1.

The IE9 exploit that Vupen used is still in IE10.

 

Well, there you go, lol. Nothing ever changes.

 

Pretty much. There's nothing drastic about Windows 8 in terms of exploit mitigation. They wrote up a post about it that mentioned some heap mitigatiosn... but the IE exploit was a heap overflow lol so I'm not exactly confident that it's working =p

 

Yep, we should get out reward also (Moonblood, Sully & Kees). It is problably caused by delay lower token of Chrome, which opens a windows of opportunity see https://www.wilderssecurity.com/showpost.php?p=2006308&postcount=77 When some exploit uses this very very small window of opportunity the normal flow of events (assigning token with Low Integrity) might be disturbed. IMO the approach to run everything with Low rights would prevent the exploit to keep the original user rights assigned to broker process. So Moonblood shoudl be safe with his all low rights approach of Chrome. Don't know what the impact of the overall security model would be (normally broker is protected from renderer processes because it runs with medium rights).

 

No, I don't think that's it. The tab is spawned and then the website is visited and then the exploit is done. The exploit didn't mention anything about a design flaw including the delayed token, it mentioned universal xss and iirc a user after free (can't remember.)

The vupen exploit bypassed the Flash sandbox, which is much weaker than the tabs. That's not super impressive.

 

The thing is, we don't know what the exploit actually involved. There are no real details, no "real" information until a few weeks from now... By then, we'll know what happened.

We don't know how it was able to write from a supposed to be low tab to a medium integrity level area. Something needed to make something go from low to medium, so that whatever was in low could write to medium.

A low integrity level object cannot write to a medium integrity level container/object , and that's why, among other reasons, the broker process, which runs @ medium/high integrity level, is there - to allow that interaction from low to medium/high. And, this can be abused, due to potential flaws in how Chromium/Chrome handles this behavior.

I'm actually eagerly waiting to know more about what exactly happened.