Sandboxie technical tests and other technical topics discussion thread

Even if that is true, it didn't really show anything what you claim (targeted malware), attacking Office documents is not impressive at all (actually, it's useless to be mentioned Duqu in the first place). If Duqu is a targeted, kernel-level based malware it should have done more, much more, but yet it didn't do anything special, so much noise over absolutely nothing.

 

I know this study very well, but I also reject it because of the way they bypassed Sandboxie, I mean using cmd.exe inside Sandboxie is not impressive at all (actually, it's a waste of time in looking this study, and only Bromium products can protect against these so-called bypasses/exploits), since we all know that Sandboxie can easily block cmd.exe from start/run in the first place.

 

Like others already have said, adding a detection option will not automatically make SBIE bloated. It can be offered as an extra option, with an on/off switch. Of course the "containment" offered by SBIE is already quite powerful, but the ability to block and notify you about malware attacks inside the sandbox, is quite cool, if you ask me.

http://www.invincea.com/knowledge-center/white-papers/

 

I only found this:

 

Yes exactly, and you need a driver for kernel hooking if I'm correct. Also, this talk about "larger attack surface" is not really interesting when the benefits outweigh the risks. And how many security tools have been exploited by malware in the last years? I can not think of one. I also want to say that comparing Chrome to SBIE only makes sense to a certain degree. Yes they both use similar sandboxing techniques, but Chrome only needs to worry about itself, while SBIE applies isolation to all apps, so of course the design will differ.

 

Thanks, I did see that, and feel it's not even true as far as Sandboxie's concerned - Sandboxie does do MS Office including Outlook (at least O2010, not O365 app-v), and certainly Adobe products if you care to have them on your machine (I don't!) It's also able to do a limited from of exfiltration protection by using blocked folders, so the only "missing" part really is the detection and enterprise management (where I think the consensus is, that's for corporates, and if you want the detection to be done that way). So it'd be great to have a technical summary of the real differences - particularly how applications which aren't on the main list get supported by Freespace, how the box is cleared, and what the exfiltration granularity is like. Sandboxie is good at being able to add on boxes for various applications you happen to have.

 

We all know SBIE is secure, but it seems people are still underestimating the security of other applications by themselves (in the real world). I don't like repeating myself, but Chrome will be the example once again.

CWS just claimed it's "easy" to bypass w/o SBIE. Where's the proof? Give me in-the-wild examples, or even an up-to-date laboratory test showing how "easy" it is.

 

Bloat is contained in thousands of lines of computer coding which MOST of us do NOT understand. It does not matter where the programming goes or what it does, too much of it eventually messes things up. The KISS principle: Keep It Simple Stupid. The best programs have always been the most pure.

Acadia

 

Bloat is not only a technical problem, it infects the organisation and management and defocusses them from the making the essential work really really well.

As I approach my dotage (some claim I'm already there) - I've come to the conclusion that software and networks actually reflect their organisations, and frequently, the empire building that happens in so many places has a direct correlation with software bloat and network insanities that are nothing to do with technology.

 

Exactly so. Also anything with a more hips stuff always kills the software.

 

It has been proven before and many times that it is easier to bypass something that relies on user-mode hooks than to bypass something with kernel-level driver and that includes every security software-I'm speaking in general and the same thing goes with Google Chrome and Sandboxie.
However everyone who claims that sandboxing Chrome is making Google Chrome less secure is not based on actual evidence, so I'm looking for evidence for this.
If Google Chrome did have a kernel-level driver I'd never use it sandboxed (since Sandboxie also has kernel-level driver), too much risk.
But since Chrome uses user-mode hooks than I decided to use Sandboxie on top of Google Chrome and it definitely cannot be less secure only more secure since we have user-mode hooks (Google Chrome) backed up by kernel-level driver (Sandboxie).

 

That makes sense to me... a lot. And unless proven the contrary I'll stick to this security approach and I agree CWS needs and me as well solid evidence, unbiased, done by experts in IT security to conduct such tests and I'll will be more than happy to drop Sandboxie + Chrome combo if necessary.

 

Kernel-level Sandboxie is only for 32 bit Windows, correct?

 

It should be kernel-level driver for Sandboxie on both 32-bit and 64-bit, but for the final confirmation I should ask Curt.

 

Maybe things have changed since the explanation of Experimental Protection as explained :

-http://www.sandboxie.com/?ExperimentalProtection

*Note* underlining is mine

also...

I've been away from using Sandboxie for a long time, even though I own a license. Maybe things have evolved to the point now where it does use a kernel-level driver? But I don't see how that's entirely possible with MS' kernel Patch protection in 64 bit Windows. Just curious is all.

 

I have already posted a question to Curt on Sandboxie forums (as Lumberjack), hopefully, I will get the answer in the next several days.

Also, please see this:
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=49&t=19837

"1) Major redesign of hooking/injection code. ASLR is now enabled for 64 bit.

2) VC Redistributables are no longer downloaded by the combined 32/64 installer. The required VC DLLs are now included in the installer binary (which is why it is much larger now).

 

Hi Wat. I posted this reply by Curt, in this thread, a couple of days ago. I think its clear (since he said it with no asterisk) that it also applies to 64 bits.

http://forums.sandboxie.com/phpBB3/...&sid=0adb397b0daec00304ea9347ef78ab92#p103750

Note: Sandboxie wants you back.

Bo

 

Thanks Bo! Well that does explain it, then It would be interesting to know, at least more or less, how they've achieved that on 64 bit. Still, I take their word for it implicitely. As for coming back to Sandboxie, well, I've transitioned to Linux mostly full time, although this old machine with dual-boot XP/Linux does use Sandboxie on the XP system.

Oh yeah, almost forgot...thank you CoolWeb for asking at invincea forums.

 

And you can bet, he will be following it up, until he gets an answer or two.

Bo

 

Like someone already said, it could perhaps also be offered in a separate SBIE version for people who really do not need it. And it's not an AV, it's actually a HIPS which give you info about what's going on inside the sandbox.

It all depends on how stuff is designed I suppose. Adding code and features does not always make apps bloated. To me bloated means: slow running GUI, slow startup time, and using ridiculously amounts of RAM and CPU time. I would be surprised if all that applies to FreeSpace which is basically based on SBIE's code.

 

You should read this article (see link). SBIE makes use of "user mode hooks" combined with a kernel mode driver. But in Windows 64 bit you can probably only hook the IRP and SYSENTER, the other ones are forbidden.

AFAIK, all HIPS (for example behavior blockers and anti-exploit tools) make use of both user and kernel mode hooks. The difference is that they can not modify the kernel anymore like they did on Windows 32 bit. But with so called "filter drivers", you can still achieve about the same, in terms of protection.

http://nagareshwar.securityxploded.com/2014/03/20/code-injection-and-api-hooking-techniques/

 

This is the reason behind Ilya Rabinovich's (DefenseWall) decision for not to make a 64-bit version of DW due to this "about the same" condition.