If you download from known, trusted sites, you should be perfectly okay. At least that's been my experience over the many years of downloading and running files only from known trusted sources. And as long as you have a sound reliable backup plan in place, recovery from a rare malicious file should entail nothing more than a trivial inconvenience. Also keep sensitive data off the machine you use for running all those downloads, or at least keep it on a separate encrypted partition. BTW, I don't participate much in these discussions anymore because I've become rather bored after so many years of trying numerous security approaches but never experience anything that breaks through them. The threat, at least for me, seems virtually non-existent as long as nothing more than just basic security measures are followed. My teenage daughter's laptop has Sandboxie containing her browser, but a while back she decided to run some gimmicky installers (at least one of which was a toolbar) outside the sandbox and infected her computer. She failed sandboxie; sandboxie did not fail her. But alas, I have a sound backup plan for all our household computers and merely had to replace her pooched system with a fairly recent backup, ran some latest MS updates, and she was back in business in short order. She learned from it as well, so she now knows better not to run such gimmicky installers again.
If it's interesting from a technical POV but irrelevant at the moment, may I ask when does it become relevant? If you want to talk about real world/life, fine... In the real world, Chrome is a widely used browser and attracts more attention but it is not as trivial for an attacker to bypass as you make it seem. In the real world, Chrome exploits are not happening on a large scale basis. To add to that, in that same real world: a) Pen-testers and hackers acknowledge how secure a browser Chrome is, despite successfully exploiting it. b) Chrome team is now making it harder for exploits (including kernel exploit) to be successful. c) Sandboxie creates an additional pathway for an attacker (just because it is not being abused does not make it any less "real") You mention browsers are not unhackable (we all know that). Why are you not making the same distinction for Sandboxie? Guess what? You are underestimating Chrome while overestimating Sandboxie. Given all that, real world proves how real and relevant my point is. But of course, my real world and your real world may differ; more so if you want to suit the definition to whatever you fancy it to be.
Anti-exe when Chrome by default policy already denies automatic execution? Outbound firewall to stop an exploit on a browser from communicating out when it could easily just piggyback onto the browser to do the work no less? No, it's blatantly obvious when someone keep downplaying the significance of "attack surface" and is so adamant that "more is better" when sandboxing is all about "lesser" interaction between data/content and the system.
That's what I've been saying all along...with the distinction that I emphasize on the latter being a poor trade-off. I do not understand why you insist on making it seem like I don't acknowledge the other side of the story. Never mind...
Actually, if you read his, mine and many of our posts completely, you will notice that the insurance aspect is already well-covered. As for this theoretical exploit stuff, you already said it yourself. In all seriousness, I'm having a bit of trouble finding what exactly is your point.
I have several questions, and I promise I won't argue with you or Hungry Man in any way: Just for the record, believe it or not, I believe that you, Windows Security and Hungry Man are the voice of reason when it comes to Chrome/Sandboxie thing-I hope my trust in all of you will not be compromised. Here are some questions: OK, let's say this all really true, Safeguy-I need your advices how to handle downloads and runnings of those files and exes, what do you suggest-that's in the case I drop Sandboxie and start using only Chrome by itself. Also-which one at this time is more restricted Chrome or Sandboxie 4.20-based on these examples Chrome is. I wonder if that using Chrome's sandbox and your mentioning of reducing permissions to the least possible and comrpomising job object proves my point that running sandbox inside another sandbox is a very bad idea when it comes to security/protection-just like I compared running antivirus inside another antivirus? I wonder how is it even possible to reduce kernel attack surface at all? And what do you mean by this: "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)." What exactly do you mean by this? Also does it mean that Tzuk (what does it mean: I would applaud them if they were more upfront and transparent (which Tzuk was).) would be able to decrease attack surface that Sandboxie provides since he was suppose to be more creative and more innovative than Invincea? Also, what about Sandboxie 3.76, according to the link on Sandboxie forums you gave Sandboxie 3.76 is not vulnerable to this-I wonder on what exactly Sandboxie 3.76 is vulnerable to, and would running Sandboxie 3.76 on top of Google Chrome (newest version) would also create holes in security and protection of Google Chrome's sandbox and increase attack surface and compromise job objects and untrusted integrity level? What about Chrome's broker process, it runs completely unrestricted/unsandboxed, should anyone use Sandboxie 4.20 or Sandboxie 3.76 on top Google Chrome and its broker process, exactly because Chrome's broker process runs completely unrestricted/unsandboxed-why or why not? If not to protect Chrome's broker process with Sandboxie, how to protect Chrome's broker process without Sandboxie and with what other security solution?
So, I should not use HitmanPro.Alert for protecting Google Chrome because of increased attack surface-right or wrong/yes or no? I should also not use AppGuard because of increased attack surface-right or wrong/yes or no? I should not use Emsisoft Internet Security or Eset Smart Security at all because of the increased attack surface? However in October I'm going to buy fresh new computer with Windows 10 (no more Windows XP anymore)-the question is what would be my security setup I'm now much more confused than ever because of this entire talk about increased attack surface and compromising job policies-since Windows 10 is very secure and I don't know what protection should I have or install on Windows 10? Tell me Safeguy, J_L, WS, Hungry Man-if everything you said is really true-what should I use for protection of Windows 10? Big thanks to all.
I never said anything about increased attack surface personally, only redundancy of using 2 sandboxes. I do use HMP.A, because it is supposed to protect against Chrome's only weakness. Not sure about AppGuard, but internet security is generally a plus and doesn't necessarily add anything redundant to Chrome. As for the system itself having more attack surface, that is theoretical and average users are far more likely to see a benefit instead. I use Windows Defender and MBAM Premium though, as a cost saving measure that should be more than enough.
Exactly, this is why I keep saying that running an sandbox inside another sandbox is like running an antivirus inside another antivirus.
Well, you're the one who keeps insisting that it's a bad idea to use SBIE on top of Chrome, and keep repeating that people should really care about possible security risks involved. When people came with counter points, you became annoyed, like you couldn't deal with the fact that a lot of people in this thread and probably also in the real world (think of Invincea Endpoint), don't care about this. But seems like it was a big misunderstanding, since you seem to acknowledge the fact that people who run Chrome combined with SBIE are pretty safe. Well, that makes two of us because I'm failing to see yours.
Nope, not the point. I'm not saying that it's easy to hack Chrome, I'm saying that IF Chrome is successfully hacked, a tool like SBIE might still save you. That's why I personally wouldn't call it a poor trade off. And if it's not attacked on a large scale, then why worry about "added attack surface" in the first place? Because it's likelier that browsers (with or without sandbox) will be attacked. Plus hackers can use kernel exploits to bypass both Chrome and SBIE, with the difference that SBIE might still be able to interfere with user mode malware if it's not directly attacked. You did mention that Chrome is less vulnerable to certain kernel exploits. Can you give some more info about this, and do you think SBIE can do the same? For the record, are you saying that some kernel exploits might work against SBIE but not against Chrome?
Like you said yourself, it's a question of risk assessment. Just because we have a different point of view doesn't mean that I (and others) don't understand how sandboxing works. And I never said that more is better, seems like you missed the point once again, but never mind. I'm talking about when the browser + sandbox is already exploited. Depending on the payload, SBIE might be able to interfere with it. Anti-exe might interfere with the dropper. If malware is executed, virtualization might interfere, think of ransomware. Good point about "piggy backing" the browser, I'm not sure if SBIE or any other firewall could deal with this.
I have mentioned this before: some of us are seeing the glass as half empty while others see it as half-full. I am fine with others having a different POV which is why I have agreed to disagree previously. Unfortunately, I am repeatedly being misunderstood and misrepresented in what I say. That kept me posting in an attempt to clear it all up. 1. I've acknowledged both sides of the story. More than once. 2. I've provided the reason as to why I see it as a poor trade-off (while acknowledging that others may see it differently). 3. I've elaborated on my reasoning with technical details in the links provided. Anyone interested can choose to follow the links and read. 4. Someone simply chooses to counter-argue and dismiss all of the above on purpose. 5. Someone claims to understand but keep questioning things which have been addressed. 6. I hope people can see why I have been annoyed. I am a human after all. Since I foresee this as going nowhere for as long as someone wants to win a pissing match, with all due respect, I am bailing out from this thread.
It's hypocrisy. When we provide arguments against sandboxing Chrome, you use the "it's all theoretical" defence. Then when you provide arguments for SBIE, that theoretical stuff becomes "supporting evidence". Basically, you're telling us we don't know for sure. Then you use an equally flimsy if not more so argument to support sandboxing Chrome as if you do know for sure. As for my other points, I've explained plenty enough. Just need to read the whole thing instead of reacting to what you perceive as against SBIE.
When you want to sandbox Chrome on a adhoc basis (e.g. for on-line banking or dodgy browsing), there is a (free) solution that does not interfere with the Chrome security model as Sandboxie does (e.g. removing Job object restriction). see post #38 in SmartObjectBlocker thread I did a quick check whether it did block other (non Chrome or Microsoft) DLL's to load, see post #41 in same thread. The rules posted in #38 are for ad hoc/on demand usage.
Wish somebody that really knew how to test this would pick up on this thread and make a youtube video. Page after page of points and counterpoints made here are certainly fascinating to read, but some empirical evidence thrown into the mix would be equally enlightening to say the least.
There were the Bromium test papers that have been conveniently ignored and even censored by one side... But that needs an update, since SBIE changed from kernel mode driver to Windows integrity levels. I doubt there will be conclusive evidence until SBIE becomes popular enough outside of security enthusiasts. Frankly speaking, I've already listed all the reasons you should be using SBIE, with a bit of addition by Sully. Here they are again (*Rasheed reminded me of something) (*bo did as well): 1) You are a click-happy user. 2) Sharing the computer with click-happy users. 3) Controlling what Chrome accesses. 4*) Targeted by elite hackers. (Purely theoretical) 5) Isolating Chrome from the system. 6) Bad habit, forgetfulness, or other condition that makes you likely to run (suspicious) executables outside of SBIE or even VirusTotal. 7) Easy cleanup and management of testbed computers. 8*) Nervous about clicking certain types of links (placebo effect realistically in at least 99.9% of cases). 9) Exploits of plugins, especially those not sandboxes by Chrome. 10) Keeping your system clean of cookies and whatnot. On all unstarred points, there are alternatives to SBIE like system virtualization, virtual machines, etc. But nothing beats the convenience and performance of running any executable under SBIE (including Chrome) to basically isolate it from the system. As for protecting installed apps from exploits... I believe there are better tools for that such as HMP.A at least in terms of convenience, and lack of redundancy for something like Chrome. I wouldn't be able to use my programs conveniently with SBIE w/o poking some holes here and there... P.S. I don't see a good middle ground between bo.elam's style of using SBIE and my style.
And for me, now after all of this information and opinion has been divulged, the million dollar questions are: (these points all assume that we are using practical assessments, not purely theoretical ones. theory is great but I want day to day plausibility for my day to day use) If I use Chrome inside of Sandboxie, and Chrome is "less secure because of Sandboxie", what are the realistic odds that "less secure because of Sandboxie" Chrome is really going to be exploited in some way. Does "less secure because of Sandboxie" Chrome somehow make Sandboxie "less secure because of Chrome"? If Sandboxie is not "less secure because of Chrome", then if the "less secure because of Sandboxie" Chrome were to be exploited, what are the odds that the same exploit would also work on a "less secure by design" Sandboxie? You do NOT have to actually answer these questions! Its not suppossed to garner an answer, as there is no true absolute right or wrong answer, only opinions. But for me, whether knowing about job objects and other OS mechanisms or not knowing, its really about if I want to use Chrome or any browser in sandboxie, why do I care if Chrome is potentially not as strong within Sandboxies virtualized environment if it does what I need it to? Why would I care if it works? It really can be only one of two ways. Either Chrome could be exploited but Sandboxie likely would not also be, or there exists a common place exploit which exploits chrome because its running under Sandboxie, and also exploits Sandboxie. And the circular question (with yet another circular answer) would be what if Chrome were to fix an issue internally that would then prevent this common place exploit from happening, even when running under Sandboxie? Or what if Sandboxie developed a way to stop said common place exploit from escaping itself even if Chrome running within was vulnerable (because it was running within). The only reason I personally would not use Chrome within Sandboxie is if there were a very common, high probability exploit that escaped chrome and sandboxie. Otherwise, I would hedge my bets that Sandboxie is going to work and don't care about the browser at that point. I only use Sandboxie for specific purposes anymore anyway. Most of the time I only use Chrome, and its normally enough. I have had my security fix for awhile now. Sul.
"If" a exploit like this exists, the question is, are we a high enough target for this to be used on? I don't worry about this type of stuff at all. All of my stuff is backed up 3 to 4x over. Yes privacy becomes an issue, but is my privacy worth looking into.
Like I said, it was a misunderstanding. In my eyes you were desperately trying to convince that "added attack surface" is really a big deal, and that people might be at great risk when Chrome is combined with SBIE. While that wasn't your intention at all. Before bailing out, can you perhaps give some more info about this?
Let's talk a bit more about this, because I'm trying to visualize it. How would exploit writers be able to profit from this? The goal is to exploit (bypass) both Chrome and SBIE. I assume they would have to write an exploit that gets them remote code execution, and privilege escalation. So what to attack? Do you have to look for holes in both Chrome and SBIE? Would you combine it with a kernel exploit? Now that I think of it, aren't you basically worried about hackers writing exploit code that will *only* work when Chrome and SBIE are combined? After all, if SBIE is not around, these "additional pathways" are not available. While instead they could have just focused on ways to bypass Chrome in a generic way, which will work on a much larger scale. Makes sense to me.
Well, my "supporting evidence" is a lot more convincing. It's based on real life, not just theory. It's a fact that if Chrome is exploited by user mode exploits, SBIE will save the day. If Chrome is exploited by kernel mode exploits, SBIE might still save the day, depending on how advanced the payload is. So protecting Chrome with Sandboxie, isn't any different than protecting any other browser. Almost all exploits that are currently in the wild, are focused on exploiting user applications. They don't take security tools into consideration. This means that you're pretty safe when using SBIE on top of Chrome, and in real life, "added attack surface", is hardly relevant. Of course, people who live in "another world" will disagree.
For the record, I want to remind you that in my first post in this thread, I already said that Chrome is pretty safe, and probably doesn't need the help of SBIE. The whole reason why I got involved is because a certain someone implied that it's a bad idea to combine it with SBIE. That's why I came with counter points, which some took as personal attacks, and started to see this whole thing as a contest. But it was all a big "misunderstanding" LOL.
See this post, I asked the same question: https://www.wilderssecurity.com/threads/chrome-sandboxed.377440/page-15#post-2512029
