Is Google Chrome truly that vulnerable?

Discussion in 'other anti-malware software' started by CoolWebSearch, Jul 6, 2014.

  1. oliverjia

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,926

    Thank you FleischmannTV for this very objective and fair comments. :thumb::thumb:
     
  2. oliverjia

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,926
    Thank you for this very useful and educational post. :thumb::thumb:;);)

     
    Last edited: Aug 28, 2014
  3. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,064
    Location:
    Canada
    Yep, a thumbs up from me on this very well explained and easy to understand post :thumb:

     
  4. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Microsoft removed that Caller false positive with the release of Update 1 for EMET 4.1 and also with the release of EMET 5.0 as well. I use Chrome with EMET 5.0 with all options checked and no issues at all over the past few weeks. I haven't had to disable any mitigations yet, running Chrome 64-bit on Windows 7 SP1 64-bit. Although I often wonder about the "performance impact" that the Chrome security team speaks of when protecting Chrome with EMET. They advise against it, but I see no harm with that added bit of protection so long as there are no ill effects, that is.
     
  5. oliverjia

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,926
    Dear WildByDesign,

    Thanks very much for sharing your experience with us!:thumb::thumb::thumb:
    I just go ahead and EMET'ed Google Chrome.
    Feel much better now, lol
     
  6. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Thanks, Bo, I have to admit, after reading this thread I almost gave up because I thought Curt will not give answer on the last question, but also Curt's last answer brings another question: the key question is: did SBIE3 at that time have what Curt says their own font parsing library from several years earlier that rejected these malformed fonts and does SBIE4 have now their own font parsing library that rejects these malformed fonts so that SBIE4 now fully protects against this kind of vulnerability/exploit, even if Windows would be still unpatched?

    This is the question I'd to ask Curt-you can copy my question there and ask Curt inside the thread if you have time.
    That's all and thanks.
     
  7. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Be happy CWS, you got today the answer to a question you had in your mind for a long time, maybe a year. I think what Curt is saying to you is that in general, Chrome is just as vulnerable to kernel exploits as SBIE is. Believing otherwise is a myth. Regarding the new question, I think you should go over to the SBIE forum and ask in your thread. :)

    Bo
     
  8. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Than what is true about AppGuard, it protects against payloads, but not against exploits themselves. Because in order for any/every/all exploits to be 100% successful, it needs malware to start/run/execute in order to infect the computer-and that's a key, you cannot infect any computer without execution of malwares in the first place.
     
    Last edited: Aug 29, 2014
  9. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Everyone is vulnerable to kernel level exploits, but the key question is, is SBIE4 vulnerable to a greater number or smaller number of kernel-level exploits than Chrome?
    This is one case where SBIE did not have any kind of protection against this exploit, while Chrome actually did, ebfore it was patched.
    I'm sure this is a gone story.
    But also, it does not matter on how many exploits SBIE4 and Chrome are vulnerable to, the key issue here is that all forms of exploits need malware to start/run/execute so that exploit can be effective and succesful in its malicious attempts, no malware start/running/execution, and exploit is 100% useless.
    So, it brings key the question, which one is better at blocking malwares, Chrome or SBIE4?

    I just don't know if Chrome has any methods at all for blocking malwares and how can you be infected except when you deliberately downlaod malwares and start/run/execute them all but SBIE4 definitely does have, and it's extremely successful.
     
  10. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    I doubt that SBIE is doing any font parsing. AFAIK it's done by browser and not Sandboxie.

    IMO, SBIE and Chrome both can't protect from kernel exploits by design. If they protect against specific kernel exploit it's only because they "got lucky" or because they prevented actions that would trigger kernel exploit (in this case parsing malformed font). Looking for software that would protect from kernel exploits is IMO unnecessary...
     
    Last edited: Aug 29, 2014
  11. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    But if Chrome is a browser, it means it can be patched against these kinds of vulnerabilities/exploits, while SBIE cannot, right?

    I wonder, why we are not attacked by kernel-level exploits more often, where is the catch?

    I mean, use kernel-level exploits like True Type font and there is no security software which can do anything about it-game over, it's one of those attacks which do not need malware to get infected, or True Type font exploits and browser exploits/vulnerabilities and all other forms of kernel-level exploits do actually need to start/run/execute malware in the first place to infect Windows/computers?
     
    Last edited: Aug 29, 2014
  12. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Chrome can be patched against exploits exploiting Chrome. Sandboxie can be patched against exploits targeting SBIE. Non of them can be patched against kernel exploits. Why would Google try to patch vulnerability in Windows kernel? That makes no sense. The problem is not in Google's product it's in Microsoft's OS. System (or drivers) have to be patched against those exploits by their vendor.
     
  13. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
  14. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I don't think you understood me, I was asking if True Type font and browser exploits and all other forms of kernel-level exploits need execution of malware to be successful in the first place, because like GraffZepellin said:
    Let's put it this way, a full version of an intrusion is carried from point A to point Z. When it comes to stopping an attack right at point A, there is nothing better than EMET. AG's Memory Guard + some other of its features can stop the intrusion chain at somewhere around point N, although with some hardening tweaks it can go up to around point F. But IMO the essential part is how to prevent it to reach point Z, it doesn't really matter where it's stopped.
     
  15. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    But if AppGuard, Sandboxie, DefenseWall, NVT EXE radar Pro and all other third-party security softwares are going to block/protect/prevent against installation of Duqu malware (and all other forms of malware) in the first place, than using an exploit (including all forms of kernel-level exploits) is completely useless, since exploits do exactly and directly need malware to infect and compromise Windows'/computer's security and protection.
    Exploited Windows' system is nothing and it's a dead end if you don't drop/install malware on it/in it, and this is where is the key distinction why all forms of exploits (including all forms of all kernel-level exploits) are useless without installation of malwares on Windows' exploited computer system, and this is where AppGuard and NVT Exe Radar Pro and all other security softwares can and will protect against.
    So in these ways it will never be possible to infect computer.
     
    Last edited: Aug 29, 2014
  16. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    But, SBIE with with tigh configuration and with Internet access restrictions and start/run restrictions does actually stop malwares from getting executed and therefore in this case, exploit is useless since it cannot be used to install and start/run/execute and kind of malware, and also it cannot have internet access.
    Of course, outside SBIE's sandbox, the game is over, it's finished before it even started.
     
  17. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Let's say we talk about exploits using vulnerabilities in general. If we say that exploit goes from A to Z I would say, patching the vulnerability would stop exploit at point A. If it is not patched exploit can continue to B1, B2, B3 or wherever it will want to go. If it will go to B1 or B2 it will be stopped by EMET, if it will go to B3 or B4 EMET won't stop it. Every software you mentioned can present an obstacle for exploit to reach a destination (which could be from Z1 to Z999) but non of them will 100% protect against it. Which of them is the best at blocking this journey from A-Z... ? I don't know. I would always choose patching over all those tools.
     
  18. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Again, it will not protect against exploits, but they will protect against malware that is trying to install itself because of the exploit, and that's the most important part, it will never be able to protect against exploits themselves, but it will be able to protect against malwares, and only with malwares your Windows computer system can get infected, not with the exploit itself, exploits themselves can never infect Windows, because it's not what they are, exploits are simply put "holes" in Windows' system that malwares use, they are not malwares themselves-that's a key difference.
     
  19. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    If exploit will try to install malware those tools will help. If it will not try to to install malware but will do something else they might not help. Also it could try to disable or bypass those tools.
    From article:
     
  20. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
  21. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Than what are exploits that do not need malware to disable system, without any security software to detect them?
    And what exactly these exploits do; I guess they destroy Windows' kernel, I suppose.
    The fact is that those links you give me still mention Duqu malware, so why waste time on Duqu malware if you can disable system without using any kind of malware?
    It doesn't make any sense.
    And if they use Duqu malware, it means that mentioned security sofwares can and will protect Windows from getting hijacked, because you still need malware to compromise Windows' security.
    Again where is the real world example where you don't need malware to compromise Windows' kernel and its security?
    In each and every case so far, they always needed malwares to do what they attempted to do anything/everything malicious.
     
  22. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Duqu is malware that is also using one exploit (TTF exploit) to propagate itself. It uses other techniques as well. Most HIPS and anti-exe software would probably stop payload from running (as I understand it launches an executable). If that vulnerability would be exploited other way (let's say without dropping and running exe) those software might not help much.
    OK let me ask you a question. How would you protect OS if there was an exploit that would target some device driver? Or un-patched svchost.exe? Would you use anti- whatever to stop driver from loading? Would you stop svchost.exe from running? Would you try to control system kernel with 3rd party tools (don't know if that is even possible)?
     
    Last edited: Aug 29, 2014
  23. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I have exactly the same questions, hopefully someone with expert knowledge can, perhaps, answer this.
     
  24. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    Hmm, referring to Sandboxie at the end, what does this mean?

    Are there calls that could be filtered/sandboxed, and could add protection, but aren't? Or wouldn't they make any difference, so optimized for performance?

    Or wait, it's not breaking the exploit and just causing a BSOD, is it?

    What does "fonts would not be processed properly" mean...? How are fonts processed differently because of Sandboxie??
     
  25. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,064
    Location:
    Canada
    Credit to Hungry Man for the following explanation:

    -http://www.insanitybit.com/tag/exploit/

    I'd say you are correct. It certainly seems perfectly logical. Hungry Man mentions this as well in his explanation.
     
    Last edited: Aug 29, 2014
  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.