Chrome 13 update patches security vulnerabilities

Discussion in 'other security issues & news' started by ronjor, Aug 23, 2011.

Thread Status:
Not open for further replies.
  1. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    57,802
    Location:
    Texas
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I still wonder if the Flash exploit was ever fixed.
     
  3. twl845

    twl845 Registered Member

    Joined:
    Apr 12, 2005
    Posts:
    4,186
    Location:
    USA
    Thanks for the heads up. :)
     
  4. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    Can't you find out via old change logs for either Flash or Chrome?
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Maybe if the vulnerability had been disclosed to the public but it wasn't.
     
  6. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    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.
     
  7. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  8. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    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.
     
  9. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  10. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    Which, again, doesn't bode well for us.

    That doesn't give me a lot of confidence.
     
  11. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  12. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    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.
     
  13. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  14. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543

    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.
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  16. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    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 :D 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.).
     
  17. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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.
     
  18. dw426

    dw426 Registered Member

    Joined:
    Jan 3, 2007
    Posts:
    5,543
    Oh good, when you find it you can tell me :D All Google gives me is a plethora of completely unrelated topics.
     
  19. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    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
     
  20. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    "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.
     
  21. JRViejo

    JRViejo Global Moderator

    Joined:
    Jul 9, 2008
    Posts:
    20,980
    Location:
    U.S.A.
Loading...
Thread Status:
Not open for further replies.