Chrome sandboxed

Discussion in 'sandboxing & virtualization' started by Overkill, Jun 25, 2015.

  1. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    It seems to be a language issue. "Bypass" to me makes it sound like there's work involved to bypass Sandboxie when you own the kernel. There is not. As long as this is clear, we agree.

    This is the bit I'm trying to explain - sandboxie was defeated the moment they got into the kernel, it is purely through the attacker not caring that Sandboxie was able to virtualize the binary payload.

    I do expect kernel exploits to become more common, but usually held for businesses as they're more valuable and not something you'd want to give up easily.


    I don't think it's too likely to be a grsec bypassing kernel exploit. Without logs, which unfortunately are not available, we can only speculate, but it seems unlikely.

    More likely it was in a web facing service.
     
  2. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    There weren't any. No open ports facing the internet, and anti-spoofing rules on iptables.
     
  3. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    You are wrong, J_L posted link where MBAE actually blocks this kernel exploit, so you are not telling the truth here, if you still don'0t believe this ask ZVL for this kernel exploit and does MBAE or not-based on what I've seen and what ZVL was answering, MBAE does block this kernel exploit, however this all means nothing if MBAE and HMPAE are both targeted by kernel exploits, righto_O?
     
    Last edited: Aug 10, 2015
  4. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I need answers on 2 very important questions in the first place, hopefully you will detect them and hopefully you can answer them both:
    I fully understand now: What you are saying is that SBIE does protect against all the payloads from all the exploits, except against those payloads which are directly designed to destroy SBIE's driver and SBIE's protection mechanisms-righto_O?

    But what about Chrome's sandbox (without SBIE's protection) than: Does Chrome's sandbox also protect against all the payloads from all the exploits, except against those payloads which are directly designed to destroy Chrome's sandboxo_O?
    If that's really true, both Chrome's sandbox and SBIE are exactly equally tough against the exploits/the payloads of the exploits in the first place, right!o_O?
     
  5. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    It seems to me that Flash is not protected by Chrome's sandbox at all, at leas that's what I still think, maybe things have vastly changed and Flash is fully protected by Chrome's sandbox, but someone needs to give us irrefutable evidences, of course if Flash truly is protected by Chrome's sandbox, than maybe Flash weakens Chrome's sandbox in the first place-the question is howo_O?

    And you are right, about MBAE, according to links MBAE does actually block this particular kernel exploit, but like I said, if MBAE or HMPA or any other anti-exploit tool is directly targeted by kernel exploits, they are dead and useless, since the payloads from exploits will directly target anti-exploit tools wose assignments is to directly destroy MBAE, HMPA and every other anti-exploit tool.
     
  6. AutoCascade

    AutoCascade Registered Member

    Joined:
    Feb 16, 2014
    Posts:
    741
    Location:
    United States
    There is an add on Sandbox program that Linux users have available to them, Firejail. There's a bit of discussion on it here http://goo.gl/ZPLcMP

    Sandboxes are only as strong as the OS allows them to be though.

    "On the Linux side of things it’s even more impressive, Chrome’s sandbox is immensely more powerful than on Windows" http://goo.gl/X9YTHN
     
  7. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I wonder exactly how much more powerful would be Sandboxie on Linux systems?
    The same as Chrome's sandbox-immensely more powerful than on Windows-or not?
     
  8. FleischmannTV

    FleischmannTV Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    1,094
    Location:
    Germany
    To you it may seem so, though actually the sandbox has been there for three years now :rolleyes:

    http://www.insanitybit.com/2012/08/...aring-ppapi-flash-to-firefox-flash-sandbox-8/

    https://media.blackhat.com/bh-us-12/Briefings/Sabanal/BH_US_12_Sabanal_Digging_Deep_WP.pdf

    What is this irrefutable evidence in your mind? How do you irrefutably proof something to someone who keeps asking the same questions over and over again, even though they have been answered a thousand times already?
     
  9. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Simple, just to confirm that Flash is under Chrome's sandbox protection, some of the posters claimed it is protected under Chrome's sandbox, some other posters claimed that Flash cannot be protected by Chrome's sandbox-I want to know what is the real truth, nothing more, nothing else.
     
  10. FleischmannTV

    FleischmannTV Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    1,094
    Location:
    Germany
    This is the irrefutable immensely powerful truth. Way more immensely powerful than other people's truth!
     
  11. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    What do you mean by that?
     
  12. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Yes, it has been common knowledge that Chrome protects its built-in PPAPI plug-ins by default since years ago. That includes Flash.

    About that, I wasn't sure whether the Flash exploits were the same as the kernel exploit, but I may be wrong...
     
  13. AutoCascade

    AutoCascade Registered Member

    Joined:
    Feb 16, 2014
    Posts:
    741
    Location:
    United States
    Most likely. I was just pointing out that a program does exist that is similar to Sandboxie for Linux users and they are using it.
     
  14. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Correct, we agree, with the difference that malware does indeed still need to disable SBIE's driver, or migrate to a process outside the sandbox. So there is work involved, and like you already said most malware don't target security tools directly.

    Yes you already said this, but that is not the point. Earlier in the thread you assumed that once a process had elevated to high integrity, it was game over, but that is not the case, as long as SBIE is not attacked. If you break Chrome's sandbox, and run with at least medium integrity, there's nothing to stop you. This is no surprise since Chrome isn't a security tool, but I'm just saying.

    Yes I wonder if M$ or third party security tools will somehow be able to protect against this. Something needs to protect the kernel, the only thing I can think of is a hypervisor.
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    The kernel is responsible for protecting itself.
     
  16. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    To elaborate on Hungry Man's point above: the kernel is the central arbiter of application requests to hardware, and the central enforcer of all software security policies. As such, it's either
    a) coded in a very secure fashion
    or
    b) doomed.
     
  17. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    AFAIK, the Hacking Team exploit was basically a combination of a Chrome hack (via Flash) combined with a kernel exploit.

    Yes of course, but I was talking about a hypervisor (HIPS) which operates on a lower level. It's the only way to block or at least detect these kind of attacks.
     
  18. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    @Rasheed187

    Another (IMO better) tactic might be to write a kernel in a safer language, like Ada 95 or Cyclone. Even C++ would provide a little more safety, as it has better type checking than C.

    Problem is, that's not going to happen because everyone is addicted to C right now. (And Linus Torvalds believes safer languages are for wimps, despite Linux's awful track record.)

    Edit: though actually, this might be a very vaild reason to compile Linux using g++ instead of gcc. :p

    (Don't mention that to Torvalds though, or he might flame you.)

    Edit: possibly another idea...

    https://en.wikipedia.org/wiki/VHDL

    ^^^ VHDL is a language for hardware design. What if an OS kernel could be implemented in hardware, in a dedicated coprocessor?
     
    Last edited: Aug 12, 2015
  19. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    @Gullible Jones
    I am a big fan of Rust: rust-lang.org

    The issue is that no one is going to rewrite the Linux kernel in rust.
     
  20. Ij80

    Ij80 Registered Member

    Joined:
    Aug 14, 2015
    Posts:
    6
    hello there, so Chrome doesn't need to be sandboxed in windows by comodo or other apps (like Cameyo) to navigate in websites that I was used to see only on Linux os?
     
  21. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Did you read the thread? It depends on your preferences and also on how paranoid you are.
     
  22. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    With all due respect, I think my solution is a better and more realistic one. What I often read about kernel exploits is that they try to inject code into Windows system processes, because normally HIPS will trust these processes. So if a HIPS (sort of like PatchGuard) runs as hypervisor on top of the OS, it would easily be able to block and/or detect this.
     
  23. What @Gullible Jones tries to explains is that you don't need a solution when you don't have the problem.

    Low level programming language like Assembler and C have the advantage that nearly everything is possble. C++ is object oriented C and has inheritated :D most of these 'the world is mine' characteristics. The designers of low level languages did not build in those limitations because that added structure and security would reduce processing speed (now hardly an argument anymore). When you use a language which has build in mechanisms to enforce more structure in memory control, ownership and concurrency, you would not have those problems in the first place.

    Futhermore Windows OS already provides C2 class strength security as Google and RE-HIPS have shown us. Also in every new version of Windows OS and compilers/interpreters additional protection mechanisms are provided to reduce the risk (attack surface :D) of the lacking restrictions in C and C++

    So your HIPS solution is not better than using a different programming language for the OS. A HIPS is less effort than recoding the OS and all applications, so theoretically more realistic. In practice however Microsoft is gradually imposing more restrictions on memory usage and ownership and the OS already contains a sandbox.

    Some OS improvements over the years. Think of DEP introduction with XP, VISTA's SEHOP, ASLR, UAC, Kernel Patch Protection, Window's 7 improving Vista's quantum leap, Windows 8 AppContainer +EUFI, Windows 10 device guard and enhanced "use after free" protection, etc.

    Hopes this helps.

    Regards Kees
     
    Last edited by a moderator: Aug 16, 2015
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes I know what he meant, but will those programming languages guarantee a bug free OS? I like to think in a more realistic approach. The things that you mention do nothing to block kernel exploits. Like I said, M$ could expand the features of PatchGuard, to not only watch for kernel modification, but also for system process modification. But anyway, we're going a bit off topic right now, I do hope we won't be seeing kernel exploits becoming common.
     
  25. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,064
    Location:
    Canada
    There's probably way more concern over this than there needs to be. As has been mentioned by others already, block ads and take it a step further by blocking 3rd party frames, keep everything up to date and don't be tricked into running something you shouldn't. And if you run Win 8 or later you have far less concern over the easier to write user-space shellcode.
     
  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.