Chrome sandboxed

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

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Not bug-free - nothing guarantees that - but much lower likelihood of bugs, particularly exploitable ones.

    Also: mandatory access control is complicated. What happens when there's a vulnerability in the hypervisor? It's happened before with Xen.
     
  2. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    Yes, stuff like SMEP and AppContainer are meant to mitigate exploits, but kernel exploits can bypass them, that's the whole point.

    Not a lot of hackers are going to try to hack the hypervisor. BTW, Safeguy said that Chrome was hardened against kernel exploits, perhaps I misunderstood, but do you perhaps know more about this?
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    That's what they said about kernel exploits a few years ago. Also whitelisting, HIPS, behavior blockers, Firefox, etc. etc. going further back. If it goes mainstream, people will try to hack it. :(

    Edit: re Chrome - on Windows, I believe it disables renderer access to a bunch of Win32 system calls. And yes, that sounds ridiculous, but it's possible because almost everything on Windows is a system call. From what I understand, it's not that different from the empty chroot jail on Linux, although... kludgier, because I don't think Windows provides a built in mechanism for it.
     
  4. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    The point is, the harder it's to hack something the less chance that we will be getting to see attacks on a large scale.

    But what does this mean? Can hackers not use this attack surface anymore?
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    The question is whether it would actually be harder to hack, as opposed to just requiring different tactics. Hypervisors are typically hard to attack because they're small. But to implement MAC via a hypervisor, you'd have to have it hooking into the guest OS somehow, and it would have to have facilities in ring 0 (with the guest kernel in ring 1) to keep an eye on things. Which means more potential for compromise. If it's written in bug-prone C like everything else, and manages to go mainstream, good luck. :(

    Another reason I'm not keen on this is that, AFAIK, the only way to implement it on Windows would be to patch the kernel via the hypervisor, so that the hypervisor could hook in - i.e. to adulterate the guest kernel. That seems like risky business to me.

    (Note though, Bromium claims to do hypervisor-based sandboxing successfully, and I have no idea how they do it. OTOH - as I've probably opined before - I am skeptical of their claims, due to the shear amount of hype and secrecy involved. Such marketing tactics are IMO ethically dubious, and make me disinclined to take Bromium at face value.)

    Not sure if they can't, but it's certainly going to be harder.
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    Yes correct, this is the way it would work. I think the benefits outweigh the risk though. The only way to ensure the integrity of the kernel is by running on top of it. It would basically be PatchGuard "on steroids".

    BTW, I believe that Invincea also makes use of a hypervisor, so that would make Invincea Endpoint a bit more robust and harder to hack, I believe. It doesn't work the same as Bromium though, you can read more about it over here:

    http://www.invincea.com/2014/05/tech-throwdown-micro-virtualization/
    http://www.techrepublic.com/blog/it...he-power-of-virtualization-to-combat-malware/
     
    Last edited: Aug 22, 2015
  7. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Than what would be Chrome's advantages (without Sandboxie) over using Sandboxie on top of Chrome?
    We talked about advantages for what is SBIE good for when you run it (Sandboxie) on top of Chrome, but what exactly are advantages of Chrome using and running without Sandboxie?
     
  8. FleischmannTV

    FleischmannTV Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    1,094
    Location:
    Germany
    1. You can enjoy using your computer again.
    2. Invincea wouldn't need to spend 99% of its human resources dealing with and fixing Sandboxie / Chrome compatibility issues.
    3. Invincea might then be able to focus on applications where Sandboxie might actually make sense, like Office 365 (for heaven's sake, people!).
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    What kind of weird question is this? SBIE is a security tool designed to protect browsers like Chrome. But like FleischmannTV said, sometimes there may be compatibility issues, so that would be reason enough to run it without SBIE on top. But the last time I checked, Chrome ran quite smoothly combined with SBIE. Of course, you could also choose another security tool to protect Chrome, like AV, anti-exe and anti-exploit for example.
     
  10. StillBorn

    StillBorn Registered Member

    Joined:
    Nov 19, 2014
    Posts:
    187
    @FleischmannTV & @Rasheed187 -- As always gents, thanks for your witticism and your erudite replies for inquiring minds that want to know. BTW, Fleisch.., if you would care to share and run into this post specifically; curious to know what your go to replacement was in lieu of the intrepid Sandboxie.
     
  11. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    To clarify, after all of this discussion it was IMO a bit of a weird answer to ask, especially because I know that CoolWebSearch has a lot of knowledge about this subject. But seems like he keeps confusing himself. :D
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    SMAP/SMEP protect the kernel ie: they make it harder to attack the kernel.
     
  13. The Red Moon

    The Red Moon Registered Member

    Joined:
    May 17, 2012
    Posts:
    4,047
    I use google chrome on linux.
    From what i understand this is a stronger sandbox than windows.

    Would this be correct.?
     
  14. Infected

    Infected Registered Member

    Joined:
    Feb 9, 2015
    Posts:
    1,022
    Yes, ive read this before also.
     
  15. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,865
    That's what our friend Hungry Man wrote.
     
  16. wshrugged

    wshrugged Registered Member

    Joined:
    Jun 12, 2009
    Posts:
    255
    Thanks for this. ^^^
    Is this true for Chromium, as well? I'm new to Chromium.
    Edit to rephrase -- This is what I get in about:

    SUID Sandbox Yes
    Namespace Sandbox No
    PID namespaces Yes
    Network namespaces Yes
    Seccomp-BPF sandbox Yes
    Seccomp-BPF sandbox supports TSYNC No
    Yama LSM enforcing No

    My Chromium version reports this as adequate sandboxing.
    From what I understand the sandbox differs depending upon the Linux distribution.
     
    Last edited: Sep 6, 2015
  17. The Red Moon

    The Red Moon Registered Member

    Joined:
    May 17, 2012
    Posts:
    4,047
    SUID Sandbox No
    Namespace Sandbox Yes
    PID name spaces Yes
    Network namespaces Yes
    Seccomp-BPF sandbox Yes
    Seccomp-BPF sandbox supports TSYNC Yes
    Yama LSM enforcing Yes
    You are adequately sandboxed.
    This is what chrome reports on linux mint 17.2.
     
  18. wshrugged

    wshrugged Registered Member

    Joined:
    Jun 12, 2009
    Posts:
    255
    My 'about' status in Mint Mate 17.2, Chromium, is the same as this ^^^^ .
    Post #492 report was from Debian Mate 8.1, Chromium.
     
  19. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,865
    That's correct. See also this post.
     
  20. wshrugged

    wshrugged Registered Member

    Joined:
    Jun 12, 2009
    Posts:
    255
  21. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    13,389
    Location:
    The Netherlands
    Yes I already said that, but SMEP can be bypassed.
     
  22. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Just a note - things have continued to improve. The SUID sandbox is removed, and the broker itself is sandboxed. I'm not overly familiar with the details anymore, but from what I can tell things have moved in a great direction. Privilege escalation on Linux, given a reasonably hardened setup, should be very costly - far less costly than other methods of attack.
     
  23. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,865
  24. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    So, pure Seccomp now? Nice. It seems like Seccomp is becoming the de facto Linux standard for sandboxing, which... well, I heartily approve of that. Standardization of Linux userland stuff is a good thing IMO.

    I wonder if they plan to support Capsicum too, though. Capsicum on Linux is a Google project, and it was originally designed on FreeBSD, so that might be better for cross platform stuff...

    https://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf

    A fine grained, capability based sandboxing implementation, portable between different UNIX systems, would be *awesome*.
     
  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.