Sergey Glazunov - Full Chrome Pwn win $60,000

Discussion in 'other security issues & news' started by Hungry Man, Mar 7, 2012.

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

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    If it turns out to be that, we should collect out prize!!! We got rights!! LOL! :D

    It should secure things. :D If my low chrome.exe can't keep things contained, then there's an issue with Windows MIC; which is kind of scary. :eek: Hope not. :blink:

    Before I applied the explicit low integrity level to chrome.exe, I gave a reading to Chromium's sandbox, and couldn't find anything to could reveal something nasty, by doing this. But, of course, there's many information there and I may have missed something, which is why from time to time I go back there and read a bit more... :D

    But, I sure will let know if I spot something bad happening. :argh:
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Not necessarily moon. The Windows MIC could be 100% exploitless with no design flaws but Chrome's own code could provide the attack surface to bypass it.

    Low integrity browser-wide is still a good idea. It won't hurt security and it may very well stop potential expoits. I don't think that it had to do with the delayed lower token though - that is a bit obvious and none of the information on the exploits hinted at it.
     
  3. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Even if with an explicit low integrity level, something could still bypass MIC, through chrome.exe, then it had to mean a flaw in MIC itself as well. Otherwise, things should role as they're suppose to role - a low object not being able to write to medium/high objects/containers.

    That's just how MIC plays.

    So, could you explore what exactly you're thinking about that an explicit low integrity level object would still be able to bypass in MIC? o_O

    As I have previously mentioned, the only way for Google Chrome code flaw to bypass MIC... It wouldn't actually be bypassing it, as it would simply be a flaw in Google Chrome way of handling it... it would be due to flaws in the low to medium/high interaction of chrome.exe being abused (I'm leaving plugins aside.), which is why we have seen Internet Explorer Protected Mode and Chrome's sandbox being bypassed and go from low to medium/high.

    You don't know, at all. Nor do I; nor does Kees1958. Only Google and the security researcher know about it.

    And, I thought Google wasn't going to release any specifics until a few weeks from now, to give users plenty of time to upgrade. So, how exactly can you affirm what didn't happen and/or what looks so obvious?

    Unless Google already released all the information, which I believe they didn't and won't so soon.
     
    Last edited: Mar 14, 2012
  4. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I don't know... but they did release at least minor details about the exploits when they patched. Nothing indicated it had anything to do with the token. Like I said, universall XSS and I think use-after-free. All of this was in Chrome code - there is no mention of tokens.

    By exploiting code it can elevate and break out of the sandbox. The code does not have to be Windows code, the code that makes up the integrity system could be flawless.
     
  5. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    There may be no indications, but that doesn't mean anything. After all, and this is something you previously mentioned, when Google faces an exploit such as the one(s) that took place, they don't disclose vital information; not until they give users plent of time to upgrade.

    Maybe there's a good reason why nothing else is mentioned. That's for sure. This is not to say that what I mentioned is involved. But, the reality is we're blind for now.

    I didn't say it had to be Windows own code. And yes, to break out of the sandbox, it has to exploit flawed code in the application. But, my question was, how would it attack me?

    You said it could still attack me. I have taken the low to medium/high interaction away. So, how will it attack me?

    I'm perfectly aware of what you're saying is true; I never denied that. But, you said it could still be bypassed.

    So, how is it that an exploit targeting Chrome, to break out of the sandbox and go from low to medium/high, will work with my configuration, if this interaction can't be abused?
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    And is it still using that delayed token? Because the exploits were patched, including the sandbox bypasses.

    I just don't see it being likely that they made use of that delayed integrity level, it's not like they don't realize that they're using it.

    You get an exploit in Chrome that allows privilege escalation. No Windows code has to be broken. The sandbox shouldn't even need holes edit: though I suppose any allow is a "hole".
     
  7. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    What do you mean? Are you asking if any other exploit could still abuse it? Abuse the same thing?

    I suppose that would depend on whether or not the part of the code that handles the delayed token still has flaw in the way it handles.

    It could very well be because of this. Also, just because patches solve this or that flaw in the way of handling, it doesn't mean that the same patch won't be introducing different ways of abusing it. It will be always a cat and mouse game.

    So, does the patching solve the issue the exploit in question abused, if it's related to the delayed token? Yes. Does it mean it solves any other possible flaw in how Google Chrome handles the delayed token? Not necessarily. That's my take on it, anyway. :)

    It's not much making use of it. It's something that's documented; but it's about abusing it. The delayed token is there; it needs to be there, in theory anyway... for the sake of convenience, or even also usability.

    All you got to do is abuse how this delayed token is handle; explore flaws in this code. Who knows... But, is it so hard to imagine there could be flaws in it ?

    I suppose you're talking about a renderer process, whichs runs @ low integrity level sending window messages to the broker process, which runs either @ medium or high integrity level, and running code with those permissions due to a privilege escalation?

    But, wouldn't that mean that the sandbox already failed as well? :D Because, the sandbox is suppose to stop the exploits.

    Anyway, I still fail to see how that would apply to me?
     
  8. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    If you have a low integrity process without any broker there can still be privilege escalation, I'm talking with the premise that that's understood, right?
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Without? o_O There's a broker.
     
  10. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I'm saying if you run some program (not chrome necessarily) at low integrity there can still be escalation by exploiting the program.
     
  11. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    OK... I thought this was about my Chromium restrictions... that's all. ;)
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Well, it is. If you run Chrome at a low integrity process it can still be exploited and run at a higher integrity. If the exploit in these pwn2own competitions has been code getting the broker to execute code, yes, you will be safe. If the exploit has been to elevate privileges from within a low integrity process, with complete disregard to the broker, it won't matter.

    Somehow this got tied into Linux I can't really keep up with conversations thi slong lol
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.