Not saying "Chrome does not need Sandboxie" is not self promoting. IMO, only someone who doesn't understand that Sandboxie isolates the entire browsing session would think something like that. And that....is something Chrome can not do. Bo
I think, Sandboxie could have something like this and already has HIPS, code injection blocking and process termination but in the form of configuration, but you have to configure it, right?
Thanks a lot for being self-contradictory. You've said what I've just said. Brush up on your comprehension skills before you question someone's understanding of a subject.
Classic fallback argument as expected: "couldn't care less" and "most users"....only now refined to become "most Sandboxie users". What was the focus of this thread again? Right - Does Sandboxie hurt Chrome's sandbox? It has never been about: Does Chrome hurt Sandboxie's protection? (which in itself is a retarded question) Does Sandboxie still work properly after causing Chrome sandbox to fail?
I'm not sure what you mean with "classic fallback argument" and how that is even relevant. Funny that you mention comprehension skills, I'm just saying that as long as SBIE correctly protects the browser, you don't have to worry about "added attack surface", I already explained why. A Chrome exploit doesn't automatically bypass SBIE, I'm only repeating this, in case you still don't understand. Perhaps it will sink in.
Here's how it's relevant: You've been using the exact form of argument to counter any points anyone else who counter you bring up. Annoying as hell. Anyway, we have agreed that Sandboxie hurts Chrome's sandbox but here's a summary of the rebuttal made so far (for those who have not read the 10 pages): 1. "Theory doesn't matter; until it matters" Everything you said is true/I agreed with your main point BUT (there's always a BUT...all the fun is in the BUT)... a) like I've said... b) attack surface is theory c) it doesn't matter d) it's not really a big issue to me e) most people (or most Sandboxie users) don't care f) I don't care g) I don't believe h) in theory, Sandboxie can help block exploits that bypass Chrome (what happened to "theory doesn't matter"??) Note to self: In theory, everything I've said is right. But in practice, someone else has to prove themselves even righter... 2. "Sandboxie can still help in certain scenarios" - Let's just pretend this has not been acknowledged. Let's repeat this ad nauseam in this thread. Highlight and magnify it's significance or suffer from the curse of infection. - Virtualization is the KILLER! (Someone has to report this to the police) - You don't understand how Sandboxie works and how it isolates the browsing session (right....please enlighten me, dear knowledgeable Sandboxie user. Years of using Sandboxie must have taught you a lot to the point where you need Curt to confirm that Untrusted IL is lower than Low. Amazing discovery! Oh yes, don't I dare even question the virtualization aspect....it's Untouchable) Note to self: If you don't use Sandboxie over Chrome, you cannot possibly be making sense. To question the value of Sandboxie over Chrome is unacceptable. And yes, virtualization is the killer! 3. "I'm going to defend the use of Sandboxie over Chrome; regardless of whether I use Chrome" a) Sandboxie has been working for me in the past few years. (My wardrobe has been working for me for the past few years too.) b) Sandboxie is a sandboxing program. Chrome is just a browser with a sandbox. (The retarded "apples are better than oranges" argument. Well, I like apples. But I don't think apples are better than oranges. More importantly, I don't want apples contaminating my oranges.) c) Tzuk says this "..." d) Curt says this "..." Note to self: Better "get this in your head" or else someone would go mad! And things will go bad! - hey it rhymes! Of course, let's just ignore the other facts! e) According to Curt, Untrusted is lower than low (Me wonder what Chrome renderers are running at ) Note to self: Sandboxie is the holy grail of security software! To challenge the use of Sandboxie over Chrome is blasphemy! 3. "Security software is a must" - "security software" being vulnerable or liability is an anomaly - "security software" never gets exploited since I've never read about it - "security software" obviously boost security. - No security software? OMG!!! - I can't live without my security!!! Note to self: Security is about piling code. Let's cover all possible scenarios. Throw in HIPS, anti-exploit tools. Not to mention of course, salt and pepper to taste. 4. "Internet cutters" - If I cannot use Sandboxie over Chrome, I might as well not access the internet then (That makes a lot of sense! By all means, if you feel like cutting off from the internet, do so.) Reminder to self: You need to stay offline more often. There's a disease on the internet.
And oh please, do quote me and throw back the very same argument I've made. It's amusing. I need to let that sink in...
Actually I need to think about this one, since you seem to be getting overly emotional and taking this way too serious. I thought we already agreed to stop this. I think I might be ready to bail out.
It's not really relevant, he was trying to make a point. But I do think that post #233 is quite amusing.
Yes correct. But I'm not so sure if it's that much easier to bypass SBIE. If people think so, they might as well stop protecting any other browser (like Firefox) with SBIE, and switch to Chrome, because Chrome is so superior. Of course, I'm trying to be sarcastic. And the question is: are these attacks, really happening on a large scale in real life? In other words, are home users affected by it?
BTW, here are some interesting articles about Chrome hacks in 2011 and 2012. In theory, SBIE might have been able to contain the payload. Of course, I'm not saying that SBIE can't be hacked. http://www.darkreading.com/vulnerab...subvert-google-chrome-sandbox/d/d-id/1097654? http://krebsonsecurity.com/2011/05/security-group-claims-to-have-subverted-google-chromes-sandbox/ http://arstechnica.com/security/201...ate-bugs-needed-to-bring-down-google-browser/
Virtualization is not an isolation mechanism, it's the opposite. It provides no protection on its own, it is only meant to enable a process to write to specific areas despite having no rights. If a process has rights, then the driver has no ability to enforce the virtualization
Virtualisation is a redirection or emulation mechanism which hides or replicates the physical environment from the virtual environment. So one could say the the virtual environment is isolated from the physical environment.
There is no emulation involved, it's a mini filter driver that sits on the filesystem. Emulation is used for hardware virtualization. File systems are logical, software, and there's no emulation involved, only a driver that sits at the top and can take in the parameters for a function and provide different parameters for the next function ie: write(/to/path) *hits fs driver* write(/virtualized/to/path)
My response: "Virtualisation is a redirection or emulation mechanism" Virtualization a) Virtualization defined through subject: - application virtualisation - desktop virtualization - hardware virtualization - partial virtualization - full virtualization - etc b) Virtualization defined through mechanisme: - emulation - native virtualization - hardware enabled virtualization - paravirtualization - etc Or defines your virtualization something different as my virtualisation
First of all, this is once again meant as "brainstorming". But I still think you're simply misunderstanding me. What I'm saying is that if you take the isolation/sandboxing part out of SBIE, it could still force applications to run virtualized, because of its driver. So let's say you run ransomware with high privileges, but still virtualized (under control of SBIE), it will of course fail to do any damage. Especially combined with HIPS which will block code injection, outbound connections etc.
No, SBIE already does this automatically, but my point was that in theory, SBIE could block suspicious and dangerous operations even without isolation. That's exactly how HIPS work. I believe older versions worked a bit like this.
Here's another exploit, but this one makes use of a OS kernel bug, so I'm guessing it would also bypass SBIE. But if it's a regular browser exploit that bypasses Chrome's sandbox, it would normally be game over. But with SBIE, it might still interfere with the payload because of its virtualization (+ isolation), anti-exe and data protection features. On top of that, it's not security tools that are being exploited on a large scale, but it's apps like browsers (+ plugins), Office software, media players etc. So it's almost retarded to make a big deal about "added attack surface", and silly to advice people to avoid using SBIE (or Invincea Endpoint) on top of Chrome, because of possible security issues. Like I said, performance issues, that's another thing. http://blog.trendmicro.com/trendlab...s-another-windows-zero-day-ms-releases-patch/
The filter driver will interrupt reads/writes to the file system. But the process will have full reign otherwise if it is not isolated via integrity - all of those things like interacting / injecting into other processes is completely outside of the scope of a filter driver***** That is enforced by integrity. The driver can only interfere with system calls that pass through the filter driver. So a high integrity process will be virtualized but not confined in any way - it can interact with every other part of the system. I understand what you're saying, I'm just trying to make this point clear since there seems to be confusion. *****https://msdn.microsoft.com/en-us/library/ff540382.aspx Wishful thinking, I'm afraid. You're assuming a payload when the only thing mentioned is an exploit that will allow an attacker to completely bypass Sandboxie or Chrome. In fact, bypassing one will almost *certainly* bypass the other entirely. I'm not advocating one way or the other. There are potential benefits and downsides, but in the end sandbox escapes are rarely dropped on users.
Yes correct, but there is no confusion on my part. I was just saying that you don't need integrity levels to block dangerous operations, why do you think I'm such a fan of HIPS? You can simply block risky stuff like code injection, process termination, driver installation etc, and combine it with virtualization to protect the system. Of course this would be a much less secure "sandbox", and that's why Sandboxie makes use of sandboxing mechanisms provided by the Windows OS itself, like integrity levels.
No you're misunderstanding. Of course a kernel exploit, like the one mentioned will bypass both Chrome and Sandboxie. But I was talking about a browser exploit that targets Chrome and manages to bypass the sandbox. Without Sandboxie on top, it's game over. Of course, at the moment you are rarely seeing this attacks, because Chrome is quite robust. Just like you almost never hear about attacks on Sandboxie.
As far as I understand your discussion, I am afraid that you are the one who is misunderstanding. Hungryman tried to explain that the Chrome (or RE:HIPS) sandbox is build on windows mechanisms. So I don't see how one could brake the sandbox without braking the windows mechanism, which as far as I know live in kernel. Hence you are talking with almost *certainty* about a kernel exploit.
