Chrome sandboxed

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

  1. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    I've been thinking and I was being silly. The so called Integrity levels have been around since Win Vista, but it wasn't until Win 8 that M$ decided to add AppContainer. What was one of the biggest differences between Win 8, Win 7 and Win Vista? Yes exactly, the so called Metro Apps. So it's very likely that M$ invented AppContainer to be able to restrict Metro Apps even more.
     
  2. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    If they think this, they haven't been reading all the posts correctly.

    Nobody is saying that Chrome's sandbox is weak. In fact, it's quite hard to hack, because "hackers" will normally need to come up with not one but several exploits to bypass Chrome. The first one for code execution, the second one for breaking out of the sandbox (privilege escalation). But Chrome is not unhackable, so it's always wise to use extra protection like anti-exe, anti-exploit or sandboxing. That is my main point.

    I already explained how SBIE can protect the system in case Chrome is hacked, even when kernel exploits are being used. Pedro Bustamante (developer of MBAE) has already confirmed that security tools are able to interfere with certain malware that are launched via kernel exploits. Chrome one its own can't do this.
     
  3. The Red Moon

    The Red Moon Registered Member

    Joined:
    May 17, 2012
    Posts:
    4,051
    may as well not bother with chrome then if all you are going to do is sandbox it.
    One of the main "attractions" about chrome would be its sandboxing abilities and yet if you are using sandboxie then the chrome sandbox is meaningless and of no use on a windows machine.

    No sandboxie on linux so firejail would be an option.so how effective is firejail and chrome and the same principle must apply in terms of why use chrome at all if firejailed.?:)
     
  4. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I would say anyone who reads this thread and does not see that both sides of the coin are being presented fairly equally needs to read the thread again. I don't personally get chrome without sbie as being weak, but instead get chrome could be better with sbie or chrome could be better without sbie. But thats just my opinion, which is but one bean in the hill ;)
     
  5. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    BTW, I was reading the Bromium report about kernel exploits who can bypass sandboxes (both Chrome and SBIE), and it seems like even when they were running a system shell (with system priviliges), SBIE still interfered with it.

    This leads me to assume that if you're somehow able to elevate your privileges inside the sandbox, SBIE will probably still block certain things, until you disable the driver, or manage to migrate to another process outside the sandbox, by hooking system calls. But I might be wrong, and this report was about SBIE v3.
     
    Last edited: Jul 29, 2015
  6. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    What? I am not sure that makes any sense. Meaningless? I personally like that fact that even in sbie chrome might be blocking bad nasties. Makes no sense to me, but I guess it doesn't have to. Only has to make sense to you :)
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    @ Hungry Man (and others)

    Something that has still not been explained (or perhaps I missed it), is how hackers would profit from this "added attack surface" when Chrome and SBIE are combined. How would this attack look like?

    And isn't it true that hackers can only profit from this "added attack surface" when they already know that SBIE is running on top of Chrome? With this I mean, if they look for holes to exploit in Chrome, how do they know about this "added attack surface", or is this something that you can automatically exploit without actually writing specific exploit code for both Chrome and SBIE?
     
    Last edited: Jul 29, 2015
  8. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    @Rasheed187
    I imagine that you have hit the proverbial nail on the head with regards those with different opinions from yours on this topic. I do believe that point is that the underlying mechanism of both sandboxes could be exploited, so in theory owning one would own both. I don't believe its about whether there is such an exploit or the potential of such an exploit, only that an exploit is possible, and that by leaving chrome outside of sandboxie is the "resistance" to it possibly enhanced, whereas within the sandbox any "resistance" is reduced.

    Thats my take on it anyway.
     
  9. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Nobody is adding anything? Well I did include isolation of Chrome in a later post.

    Another may be that you don't always pay attention to what you install, whether that be a habit, illness, etc. In that case, being SBIE will save you from your forgetfulness.
     
  10. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    How about
    E) testbed environment with easy cleanup
    F) easily manage testbed environments
    G) nervous about clicking on certain types of links

    Sul.
     
  11. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,794
    Now, there have been reports about Chrome escapes (kernel exploit or otherwise). However, these are not occurring on a widespread basis as imagined to be. Quoted examples of bypasses in real-life are not a strong case when the foundation is weak in the first place. Even skilled pen-testers and "hackers" acknowledge the extent that Google team has placed in securing their browser. If you don't run as admin & keep your OS & browser up to date, the chances drop even further.

    Furthermore, when we look at the respective implementation of the sandboxing mechanisms, Chrome's sandbox is more robust than Sandboxie.
    This is even more so now with the Win32k lockdown mitigation (which disallow calls from user mode that are serviced by win32k.sys) and AppContainer on Win8 (which even Sandboxie has not been able to utilize).


    As far as virtualization goes, no one is stopping anyone here from using Sandboxie as a test-bed environment.
     
  12. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    As much as I dislike auto update anything, I do let chrome update even if I hate the time it takes to start every day. I think yours is a fair assumption of the likelihood of an "escape". And thats really how I've looked at things for a long time now, that its possible, but is it likely. My experience, with what I do and how I do it, is that the likelihood is very small.

    However, there is a large difference to me in one respect, and that is not a true exploit (aka virus/hack/trojan etc) but rather the socially engineered exploit that is "allowed" to happen by the user. So while I have a pretty large degree of trust that chrome is updated enough to take care of itself, I don't necessarily trust myself enough to always steer clear of socially engineered exploits, thus sandboxie brings with it a certain form of insurance that chrome itself cannot. And it does it even though my system is never updated and always has root.

    It is so fascinating the different ways we each go about solving a threat that has no real shape or definition. Some pile up all kinds of tools against the worst threats imaginable, some do nearly nothing for the same threats. Yet, none of us really know what the threat might be that gets past us, and may never know what threats were stopped. The topic of pc security is so frustratingly addictive lol.

    Sul.
     
  13. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    3,924
    Location:
    Mexico
    +1 :thumb:
     
  14. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    That win32k lockdown mitigation does not mean anything at all, it only means that the newer Windows are, the more restricted Chrome and Sandboxie are also-that's nothing big deal here-again it all depends on the Windows version or Linux version where they are installed and where they both run.
    I fully agree with Rasheed when it comes to issues if Sandboxie should protect and run on top of Chrome.
    Added attack surface is a double edged-sword and there are always 2 sides of one coin/story, the other more unpleasant story/reasons of attack surface which seems to be ignored by Sandboxie and Chrome experts here on this forum.
     
    Last edited: Jul 30, 2015
  15. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Like I said anyone can survive without pretty much an security if he/she does not download and run anything and does not visit risky websites, right now I'm in the position that I'm on the job where demands are to download and run everything, and that is why I have Sandboxie, not because of the Sandboxie/Chrome issue thing.
    Despite I'm sending all the files, exes and programs on malware analysis and send them on virustotal, sometimes even that is simply not enough, so if anything goes wrong it goes wrong inside Sandboxie, not outside of it-that is all based on my experience.
    Like I said before, if anyone wants to run Chrome inside Sandboxie I strongly recommend-disable Chrome's sandbox first.
    Forget about attack surface and similar things, it's not about that it's about the fact that mixing 2 sandboxes, running one sandbox inside another sandbox is a truly bad idea-like running an antivirus inside another antivirus-it can only decrease security/protection thing.
     
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    I must admit, I didn't understand everything in your post. But to clarify, I'm just trying to visualize how an attack on Chrome + SBIE would look like. I can imagine that you would first have to exploit the browser (for code execution) and after that you would have to exploit SBIE, to bypass the sandbox. But that isn't any different from how you would try to exploit Chrome, unless I'm missing something.

    Also, my main issue with the "others" is that if they would say that Chrome is already pretty secure, and because of that you don't really need SBIE on top, I could live with it. But instead they are saying that if you choose to run SBIE for extra protection, you actually might be more at risk. I'm sorry but that sounds very silly to me. When you think of it, that sounds more paranoid than people who run multiple security tools, just to cover all bases LOL.
     
  17. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    That's cool and all that Chrome is perhaps 10% more robust than SBIE. But does it have any true meaning in the real world, that's the question. Let's say that Chrome has a installed user base of 40% and SBIE only 5%, which is more likelier to get attacked? And then there's the issue of kernel mode exploits, who can bypass both Chrome and SBIE, so there's not even a reason to look for holes in SBIE.

    On top of that, because SBIE does more than just isolating (virtualization, anti-exe, outbound firewall), there is a big chance that it will interfere with payloads who manage to bypass Chrome's sandbox (with or without kernel exploit). Of course in the case of a kernel exploit, it's also game over for SBIE if it's directly targeted by the payload.
     
  18. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Exactly this, you hit the nail, Rasheed, excellent points, it looks like some people who are even experts in these fiealds just don't realize this, especially that part that Sandboxie on top of Chrome would mean more risk because of the increased attack surface.
    This would mean that all the people on this board who run multiple security softwares are at so much greater risk, that they would like open door to all hackers and they would actually "say" to hackers-"we have vastly increased attack surface in our Windows system, come and hack us"-yeah right-if that was really true, the entire population who uses multiple security solutions on thier Windows system would already be hacked so many times because of this vastly increased attack surface, caused by multiple security solutions and options like running Sandboxie on top of Chrome.
     
  19. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Look at my answer here, it doesn't make Chrome tougher at all, it's the Windows system that you are using:
    In Windows 8 and above, win32k lockdown decreases this so-called attack surface by locking win32k-Chrome by itself does not do that (neither does Sandboxie), Windows 8 and above does, so this example is a moot point since it will make both Chrome and Sandboxie and Sandboxie on top of Chrome at the same time more robust and more restricted than it already is.
     
  20. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,794
    You are looking at it from a numbers game. I am looking at it more of a design perspective.

    If we want to count likelihood, I would counter it with the same question: how likely would a person face a Chrome exploit ITW? Not very likely if one practice safe computing practices.

    It's not about looking for holes in SBIE. It's about SBIE creating holes in itself. I know this is hard for some people to swallow. People are not used to the idea that security software in itself can be a liability.

    People don't understand how sandboxing really works and are going based on their experience of what they see in SBIE settings and assume it's how sandboxes work in general.

    Sandboxing architecture is all about reducing permissions to the least possible (as can be seen even in Sandboxie's architecture since V4). Thing is Chrome already does that well on it's own, without the need for anything else to interfere.

    Adding Sandboxie over the top messes the whole thing...what with it compromising job policy (allowing child processes to be started), injecting DLL and the system service.

    From having very little to access in vanilla Chrome, a potential attacker now has resources to work with that are otherwise non-existent in the first place.

    Chrome's sandbox policy already has a very restrictive token (privileges:none), runs under a job object that only allows one active process limit (disallows creating child processes) for it's renderers. Now, the Chrome team has done things to reduce kernel attack surface (and by that, lessen the likelihood of a kernel exploit succeeding).

    Plenty of people look at Sandboxie's virtualization aspect as a form of "insurance". I do get that it is very assuring that if something bad were to occur, it's going to be easy to undo. Trust me, I share that same sentiment. I have used Sandboxie over Chrome before.

    I have mentioned it a couple of times already that I give credits to Sandboxie for the "virtualization" but with a caveat: that "virtualization" does not really secure objects. That "virtualization" is simply a redirection.

    It's the restrictions, the permissions, the privileges where the true sandboxing architecture gets it security from which is why the 2 sandboxes conflict. But instead of acknowledging that Chrome's sandbox can stand on it's own, the Invincea team would rather you disable Chrome's sandbox so that customers can run theirs. I would applaud them if they were more upfront and transparent (which Tzuk was).

    Do people see where I'm getting at now?

    I am not denying the "insurance". What I am bringing up is the idea that the "insurance" that people feel so comfortable with comes at a cost too high.
    In exchange for that blanket of "virtualization", that "insurance" that keeps them feeling warm, they are trading for a weaker and less robust security design.

    Essentially, I am calling it a poor trade-off. For others, it may not be.

    If my crystal balls prove me right, people would still not understand and miss the point altogether.
     
    Last edited: Jul 30, 2015
  21. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    When you said this
    It made me think the thought of exploiting both, without specifically targeting one or the other, seemed to be a core concept of those who would not run chrome in sbie. Because they both use the same underlying mechanisms.

    And, as safeguy has just posted, the tradeoff for using chrome inside sbie without its own sandbox would perhaps not be that great, as chrome utilizes some things that sbie does not. It does not imply it will happen, only that given the facts, chrome has something sbie does not so it makes sense to use it.

    I have not looked, but might, at why it would even be a concern to turn chromes sandbox off within sandboxie. The way I use it, when I do, I would think I want it to behave as normal within the virtual environment, and would assume that 99.99% of the time anything I might encounter would never escape chrome because of its sandbox. Which leaves me only worrying about socially engineered aspects or hijacked websites that try to auto execute or trick me into executing.

    Sul.
     
  22. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    Actually you're point is quite clear. From a technical point of view it's interesting, but in the real world it's not relevant at the moment. Basically you're saying that if you had to choose between Chrome (with internal sandbox) and Chrome protected with SBIE, you would choose the first, because in theory it's easier to exploit SBIE than to exploit Chrome.

    And that's cool and all, but you're totally overlooking (or ignoring) all the other points that I mentioned. That is stuff that matters in real life. I do agree that browsers like Chrome and the new Edge don't need SBIE on top if you're only worried about mitigating exploits. But these browsers are not unhackable, and more likely to be attacked than SBIE. And who is going to save the system when Chrome or Edge is bypassed, either with or without kernel exploit? You already guessed it.
     
  23. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    Yes exactly. End conclusion:

    - People who choose to rely on Chrome are pretty safe.
    - People who choose to protect Chrome with SBIE are pretty safe.

    Why? Because both Chrome and SBIE are not attacked on a large scale. Both offer robust sandboxing, but because Chrome only needs to worry about itself, it's a bit more robust and restrictive.

    Which one is more likely to get attacked if you look at it from a "numbers game" point of view? Probably Chrome.

    Which one is easier to hack? SBIE probably has more "attack surface", but AFAIK that doesn't automatically mean it's easier to hack. I've read the infamous Bromium report about kernel exploits and they were able to bypass both Chrome and Sandboxie with the same exploits.
     
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    Not the point, virtualization might interfere with the correct working of malware that has managed to get system or high integrity. Same goes for anti-exe and the outbound firewall.

    Now you're just assuming stuff.
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,101
    Location:
    The Netherlands
    Once again I'm not really following you. Are you talking about kernel exploits? Yes, they are known to bypass both browser and application sandboxes. But from what I've read, they are often used in the second stage of the attack, in the first stage you need to achieve code execution, this is usually done by exploiting flaws in the browser, not by abusing flaws in security tools.

    About SBIE interfering with Chrome's sandbox, isn't SBIE doing all the isolating? So should we even care? With that I mean, as long as Chrome is working correctly, I don't see the problem. And is there a way to disable Chrome's sandbox? Didn't know about that.
     
  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.