The Chrome in the wild exploits inventory

Discussion in 'other anti-malware software' started by Windows_Security, Feb 20, 2015.

  1. Currently there is none I could find :p. . . but maybe doom and damnation dreamers can help me to build up a list :D
     
    Last edited by a moderator: Feb 20, 2015
  2. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    The idiot click-happy user is the most dangerous exploit of all. You'll need to restrict them from installing anything. ;)
     
  3. guest

    guest Guest

    In general, you will need at least two vulnerabilities to exploit Google Chrome. one for Flash/Chrome and one for the sandbox or the kernel.
     
  4. Sordid

    Sordid Registered Member

    Joined:
    Oct 25, 2011
    Posts:
    235
  5. Last edited by a moderator: Feb 20, 2015
  6. guest

    guest Guest

  7. Sordid

    Sordid Registered Member

    Joined:
    Oct 25, 2011
    Posts:
    235
    I was actually avoiding making a statement and forcing inferences considering there really isn't a need for an exploit list granted we know a vuln exists; those are the public disclosures--it is what it is. Old, indeed. Now most Chrome related security research is gathered privately under Google's bug bounty. There are no metasploit modules available as linked and Vupen doesn't usually play nice. You could try searching the CVE codes, but that would probably be timely and fruitless.

    So, still really want a wild exploit. Look at popular crime/exploit kits. After all, that is what the user/browser is actually facing in the wild. However, one soon will realise Chrome bypasses in exploit kits usually/virtually always affect plugins, namely the unsandboxed Java plugin which imo is a Java fault, not Chrome's.

    TL...DR: stop looking for "Chrome" exploits, look for plugin exploits that affect Chrome.

    & Ah, semantics! Called exploits because they "exploit" a vulnerability. So yes a POC "exploit" would crash Chrome in regard to CVE-2010-1029...just sayin'...but boring and lame though, I know.
     
  8. Good to mention the Achilles heel of any sofware: plug-ins and extensions (third party alterations). :thumb:
     
  9. Since I sort of secured my PC with insecure internal OS-mechanisms, the only reason to return to this forum is to put on my red nose and debunk myths about malware mayhem, so thanks for the excellent wrap up.
     
  10. Brummelchen

    Brummelchen Registered Member

    Joined:
    Jan 3, 2009
    Posts:
    5,871
  11. @Brummelchen Three things,

    1) Please don't mention FF in a security forum (or at least have the decency to NOT mention the FF-word in my threads). I know your are an experienced member, but when people with some security knowledge start mentioning FF, less experienced viewers/lurkers might get the idea FF is safe to use: FF lacks a sandbox or policy container, without use of additonal security as Sandboxie or AppGuard for example one should not use FF.

    2) Script blocking can't compensate for browser weaknesses. As soon as you whitelist a website, the website could be hacked and your scriptblocker would not protect you. The whitelist concept does not apply to code hosted on other computers (as is the case with scripts and rich content). Simply because you don't have a clue about the integrity of the code hosted elsewhere.

    3) See thread title: not talking about CVE's but CVE's succesfully exploited in the wild

    Untitled.png
     
    Last edited by a moderator: Feb 22, 2015
  12. Solarlynx

    Solarlynx Registered Member

    Joined:
    Jun 25, 2011
    Posts:
    2,015
    1. Obviously it refers to its derivatives like Palemoon ets?
    2. Are FF and its derivatives safe under EMET or MBAE?
    3. Are they safe when a good HIPS like Comodo's D+ (for instance in "Safe Mode") is installed (but not additionally tuned it to restrict the browser itself).

    Thank you.
     
  13. guest

    guest Guest

    It depends

    EMET only offers an additional layer against exploits targeting memory corruption vulnerabilities, but it should be quite trivial to modify an exploit in such a way that it's able to bypass EMET. Personally I think that MBAE and HMPA offer greater protection.

    With regard to HIPS: It's an additional layer that could reduce the impact of an exploitation attempt.
     
    Last edited by a moderator: Feb 22, 2015
  14. Solarlynx

    Solarlynx Registered Member

    Joined:
    Jun 25, 2011
    Posts:
    2,015
    Thank you.
     
  15. 142395

    142395 Guest

    I don't know proper word, but maybe I can call it "mischief"?:D
    Anyway, someday finally ITW exploit will be found and then this thread have to be waked up.

    If you don't limit "exploit" to RCE, this can be candidate.
    http://blog.trendmicro.com/trendlab...e-bypasses-chrome-extension-security-feature/

    Also, Sordid is not fully correct. In the past surely plugins were not protected by default and you had to add --safe-plugins flag to protect them, but now plugins are sandboxed by default tho average user can easily disable it cuz Chrome gives popup asking if he want to allow direct system access for plugin (same reason why MS Office's protected mode is not effective). You can change this behavior from settings to force plugin sandbox.
     
  16. guest

    guest Guest

    It doesn't make sense to call that an exploit.
    An executable has already been executed by the user in the example you just mentioned.

    It would be the same as claiming that Windows contains an 0day vulnerability because anyone is able to make an executable run automatically at start-up/log-in by adding a key to the registry.
     
  17. 142395

    142395 Guest

    It can be well called exploit as it bypassed Chrome's intended security measure. Not all vulnerability or security hole need or will be patched, but at least Chrome team should/can take some measure (maybe sig enforcement, tho it will trouble advanced user who want to install non-store extension).
    For me RCE is just a small part of exploit in whole exploit (broader meaning).
     
    Last edited by a moderator: Feb 23, 2015
  18. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    It seems to my that you have clearly demonstrated why do you need sandbox Chrome with Sandboxie with this example.
     
  19. 142395

    142395 Guest

    I think you completely misunderstand what he meant. But I leave reply for Kees.
     
  20. You clearly outwitted me with this reply, may be you could add some logic (intermediate reasoning steps) to this statement
     
    Last edited by a moderator: Feb 23, 2015
  21. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    Why are you bringing that up again here? It has been explained countless times already.

    Unfortunately, blind faith or extreme fanboyism makes it hard for people to see reason and they go about refusing explanation to see why it makes no sense. It's not an attack against Sandboxie per se (because Sandboxie is one of the better security apps for Windows). It's just us saying NO to adding Sandboxie to Chrome. Separate these 2 and get emotions out of the picture.

    Chrome sandbox can pretty much stand on its own feet. We are not saying it is invincible (because it is not). However, that does not mean adding Sandboxie to it is a good idea.

    If you think Sandboxie can serve as an additional layer in case something escapes Chrome's sandbox, let me just say this:

    1) Sandboxie's sandbox is even less restrictive by design (to ensure compatibility with as many apps as possible).
    2) Sandboxie's sandbox is less vetted by the security community compared to Chrome's.

    Even if we were to neglect all that and assume a positive benefit, there is still the possibility of 1 sandbox interfering with the other and breaking either one or both sandboxes. The trade-off is not worth the effort.

    Simply said, "double bagging" is counter-productive.
     
  22. Brummelchen

    Brummelchen Registered Member

    Joined:
    Jan 3, 2009
    Posts:
    5,871
    1. chrome has its own sandbox - or precisely: chrome uses windows functions to create its sandbox*. like firefox will do. like flash do, like adobe reader/acrobat do, like java do.

    2. firefox gets its own sandbox with version 36 - in some days when rolling out starts. a bit late but nothing to blame. same time it gets its own protected mode for plugins, in special flash.

    3 i need to correct a link - chrome cve - in total 38 for 2015
    http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224

    while firefox has 10
    http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452

    in total chrome (webkit) where practically a desaster to collect almost same amount of discovered flaws in nearly half of the time.

    of corse not, but that seems not to be discussed here.

    /ot
    but that is expected to work close to 100% compatibility. but as i stated in another thread here - sandboxing a browser is no big gain concerning security while users are using their normal hosting system and regular browser profile. the browser and its components still are vulnerable and with default settings anything can be read out and send into the web.

    it took me 2 seconds and google to discover it. google blame its own browser ^^

    browser bashing? an a versus b comparison?

    PS
    *
    http://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html
    Flash Player "sandbox" - so called "protected mode" (same model for adobe reader/acrobat)
    https://blogs.adobe.com/asset/2012/06/inside-flash-player-protected-mode-for-firefox.html
    mozilla sandbox
    https://wiki.mozilla.org/Security/Sandbox
    the result of the latest co-op between google and mozilla - at least both share ideas and code. mozilla has the best javascript engine and google gets some code back to improve its engine - aso.
     
    Last edited: Feb 23, 2015
  23. Good to see that you discovered some documentation about the Chrome sandbox mechanism. The whole development idea of Chrome is about being humble and re-using as much as possible. Currently there is no commercial company which has implemented re-use (and regression testing re-use) as much as Google. The Google online security blog is a nice read when you would like to know more about this topic. http://googleonlinesecurity.blogspot.nl/

    See thread title: not talking about CVE's but CVE's succesfully exploited in the wild. Just open the CVE, find it in the Google release documentation and you will notice that the disclosure dates are the same (as I tried to illustrate with the picture in post #11)

    This is a thread about Chrome, you started to mention FF in this thread and you started comparing CVE's. Are you serious?
     
    Last edited by a moderator: Feb 24, 2015
  24. 142395

    142395 Guest

    Flash protected mode is almost joke so Mozilla is now considering to disable it by default. There has not been any ITW exploit which could be blocked by protected mode. Adobe Reader's one is much better, but it have been bypassed at least twice in targeted attack as it uses looser configuration than Chromium, tho basically same sandbox. But there have not been any ITW RCE exploit which bypassed Chromium sandbox.
    CVE number don't reperesent browser security. We already had quite a discussion about it. Now I see new survey shows Linux and iOS had much more vuln than Windows, but it doesn't necessarily mean Windows is more secure. If you looked into those CVE's details, you'll find most of them can't be used to penetrate Chrome. DoS vuln and memory read vuln itself don't make code execution or other serious security breach. Also if you simply searched, it will include all version (Linux, Android, iOS) of Chrome which are different products. BTW Chromium ditched Webkit and now its rendering engine is called as Blink.
    To make it compatible with Chrome, they made some compromise and sandboxed Chromium has more job objects than unsandboxed. Also SBIE runs Chromium broker in untrusted integrity which is, I believe, not good from Chromium's view.

    I don't know which sandbox you meant, but when Chrome was compromised, still compromised renderer process has almost NO right, it can't access any files or registry on your system except allowed one which determined by policy nor can make network connection, and they are still well restricted. To abuse this, you have to locate and disable WebSecurityEnabled flag firstly, then send cookie or so via XHR (but once --enable-strict-isolation become default, even this attack become impossible).

    Also for SBIE, you can set access block or read-only for each folder and registry. This greatly reduces risk of info theft.

    See Kees' post. It seems you're confusing PoC with ITW exploit.
     
    Last edited by a moderator: Feb 24, 2015
  25. Sordid

    Sordid Registered Member

    Joined:
    Oct 25, 2011
    Posts:
    235
    This is not accurate. The deprecated "--safe-plugins" flag applied the sandbox to Flash which is now enforced by default (with PDF added later). Java runs in its own sandbox as an explicit executable outside of Chrome and its protections.

    Unless Oracle recodes, the Java NPAPI plugin will be completely banned from Chrome.

    Force sandbox switch in settings? You just said they are forced by default with a prompt to "unforce" it. So which is it.

    Also, a moot point:
    “That is also why I think something like Java can never be secured against hostile code running within a sandboxed environment,” Forshaw said. “The attacker has too much control to craft the environment to exploit the tiniest of weaknesses. The large amount of trusted code bundled with the JRE just acts to amplify that power.”

    http://threatpost.com/chrome-and-java-pwn2own-vulnerabilities-explained/99835
     
  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.