Chrome 13 update patches security vulnerabilities

I still wonder if the Flash exploit was ever fixed.

 

Thanks for the heads up.

 

Can't you find out via old change logs for either Flash or Chrome?

 

Maybe if the vulnerability had been disclosed to the public but it wasn't.

 

Ahh, okay. I didn't know about that. You're speaking of the one that broke out of the sandbox, right? Or is this a separate issue? Either way, yeah I really hope they got on that. In the wild or not, it's still an issue, and, it can go "in the wild" at any point. All it takes is the right info in the wrong hands.

 

Yes I'm talking about the Vupen exploit, which used a Flash vulnerability to break out of Chrome's sandbox and execute arbitrary code at medium integrity.

Apparently it was a buffer overflow attack. For all we know it could have been patched way back when but Vupen hasn't said anything (except after one of the Chrome security releases they mentioned that it still existed) and the Chromium/ Adobe teams don't have a ton to go on.

 

As far as I know, Vupen still basically provides details to government/paying customers. So, it's quite plausible neither Google or Adobe still has any idea because they didn't pay enough. So, while the government very likely does know all about it, those two companies might not, therefore exposing us all. Note I said plausible, though the lack of information from Google on it (if they patched it, it's likely they would have come out and said so), doesn't bode well for us. That's the bad part about being too confident. Most praise Chrome's security, and rightfully so, but we have to remember that the Charlie Millers of the world aren't the only ones trying to poke holes in things. There are plenty of Vupens out there.

 

I don't think Google nor Adobe would even know if they'd patched it. Not enough info.

I don't think Google has patched the sandbox since the early beta versions.

 

Which, again, doesn't bode well for us.

That doesn't give me a lot of confidence.

 

They haven't really had to patch the sandbox, it's never been broken before. I also am not positive but I'm fairly sure.

I think they're satisfied with the level of security that the sandbox has given them - a single exploit in over 3 years is a very nice track record.

 

No doubt, it's a great record. It's just the idea of that exploit existing, and the irresponsibility of Vupen that bothers me. Well, that and the fact that it's a Flash exploit. You can't even hope to block it with another method, seeing as how no one but Vupen and who ever paid them has a clue as to how it works.

 

Not sure if EMET does anything. I know it bypasses ASLR, SEHOP, and DEP.

Further sandboxing Chrome would work. I know CIS monitors programs for buffer overflow attacks.

 

Yeah, I suppose with a locked down SBIE (or equivalent sandboxing program), you could contain it at the very least. I have high doubts EMET would help matters, considering it would bypass just about everything EMET tries to force upon programs.

 

I don't think that Chrome uses quite everything that is supported by EMET v2.1. I just don't know if everything that EMET v2.1 supports is relevant to this particular buffer overflow attack - we already know that DEP, SEHOP, and ASLR are out.

 

I had thought Chrome supported all but EAF in EMET, but, considering I barely know what EAF is, I'm not sure that is at all relevant to this conversation Anyway, the only thing we can really do is assume this issue still exists (no reason not to, consider not a word has been heard of it since the exploit was revealed.).

 

I honestly don't know what Chrome has by default other than DEP, SEHOP, ASLR.

I don't think EAF is relevant to buffer overflow. I have it disabled anyways since it breaks Silverlight for me.

Reading up on EAF now.

 

Oh good, when you find it you can tell me All Google gives me is a plethora of completely unrelated topics.

 

Yeah... hard to find a decent article on it.

Picking up bits and peaces where I can find them haha

Though one of the first articles I found shows how to bypass it =p

 

"EAF works by setting a hardware breakpoint on the export address tables of the ntdll.dll and kernel32.dll modules in a process. When the breakpoint is triggered, EAF determines if the code that is trying to access the export address table is valid code for that process or malicious code injected into the process through an exploit. Most exploits will at some point inject and run shellcode into the target process. One of the first thing most shellcodes do is determine where certain functions are loaded in memory. This is commonly and easiest done by going through the list of loaded modules and reading their export address tables. When shellcode reads the export address tables of ntdll.dll and/or kernel32.dll, EAF detects the shellcode and terminates the process, preventing the exploit from running successfully."

http://skypher.com/index.php/2010/11/17/bypassing-eaf/

As with every other mitigation technique for EMET it's bypassable but will break older exploits.