Sandboxie technical tests and other technical topics discussion thread

Not me, Rasheed, all I want from Sandboxie is to remain being what it is....the best application sandbox in the World.

I ll add something. If you gave me the choice of trading my SBIE lifetime license for a lifetime license for Free space.....I ll keep Sandboxies.

Bo

 

Hi CWS. In my personal case, if I was a Chrome user, the impact of sandoxing or not sandboxing Chrome would be huge in the stress level that I experience while using the internet. My stress level right this moment and its being like this for 6 years is about a 1 in a 1 to 10 scale. If I was to run Chrome unsandboxed, the level would shoot right up immediately to about 6 or 7.

Bo

 

I actually cringed when I read this. Sandboxie is not a detection tool and I pray they never try to turn it into one.

 

Why not? Some of us want it... xD
Besides I already said a good idea would be another edition, a separated one with this malware detection feature, the other one remains the same.

 

In fact, the original reason why Tzuk created Sandboxie was......because detection tools fail, sometimes.

Bo

 

I would like to see a proper comparison between Freespace and Sandboxie (I don't have time to do an eval), and also any confirmation of whether they are considering a hybrid or migration between the two.

One thing that does seem fairly clear is that Freespace is somewhat limited in the controlled applications, although it does flag up bad behavior within the box. A showstopper for me is that it only appears to id the box application by file extension, and doesn't have the granular file restrictions that Sandboxie has (making a disk firewall) - however, I'm talking from a lot of Freespace ignorance here.

As others have said, I'm very delighted for Sandboxie to do what Sandboxie does, and all that needs to happen is for it to follow the graunch of changes which cause issues (like Chrome updates).

The only functionalities that I want improvement on are support for Office 365 App-V and some better ways of defining file access and restrictions.

 

In my opinion, this is very important and has to be done.

Bo

 

That would be consistent with Tzuk working with Invincea for quite a while - and I'd also be delighted if so because it hopefully means one codebase that's supported.

 

deBoetie, look around the middle of the page.
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=19642&start=15

Bo

 

Agreed!! I've seen too many programs that have started out good but got ruined by bloat!
Acadia

 

As long as it's essentially an add-on, I'd see that a Sandbox is in fact in a good position to evaluate what's going on in the Sandbox, particularly if tuned to a particular set of popular applications (as Freespace is). So, any behaviours which go outside the normal pattern would be much easier to evaluate from the frame of a sandbox, seems to me. And for business, getting intelligence about attacks is valuable, not just being able to fend them off - because they may come back in other ways.

I'd agree though that you want to be able to pick the relevant set of tools that cover your threats and priorities, not have bloat and redundant functionality (which is dangerous in its own right).

 

Actually I already posted about it in #96

Well, Tzuk said still SBIE has many differences from Chrome in below link, but her example was not directly related to security but it's more realated to program compatibility & usability.
http://forums.sandboxie.com/phpBB3/viewtopic.php?t=14454
So I continue to assume SBIE 4.x has many duplication with Chrome regarding security.
But it is well possible that still SBIE combines hooking for protection as Windows_Security suggested, though I think it brings not only benefit but potentially another attack surface if that's true.

BTW can anybody post a link which Windows_Security mentioned in #188 as a post of Curt?

CWS, don't forget I keep saying that sandbox Chrome by SBIE has huge benefit for many people as SBIE care about even after downloading executables, opening potentially malicious documents, and also privacy threats.
Chrome basically doesn't care about those with only a few exception like PDF viewer.

Also I don't understand why you care so much about really unusual case, i.e. you are targeted by NSA, 61398 unit, or any other organization who don't care about spending lots of money & time to infect you, this is a kind of APT―Advanced Persistent Threat.
Can you give us a clue why you can be targeted by them? Well, it's kidding (somewhat). I don't think you'll be targeted by such an advanced cracker.
But what you're keeping to ask is such a situation, nothing else.
Even most advanced malware which we can come across in the world won't penetrate either Chrome or SBIE. And this won't change at least 2-3 years (maybe much more, but nobody knows future).

As Jarmo said, there's no software which protect you from everything, but I somehow feel you're wanting such a perfectionism for SBIE, or waiting someone assure that.
Sorry, nobody can offer that and if anyone said that you have to be careful.

As to attack surface, I don't count it as an attack surface reduction when SBIE successfully contained what penetrated Chrome protection. This is just an another layer or protection, but not a kind of attack surface reduction.
IMO even MBAE increases attack surface for Chrome as it make Chrome load a dll, but I believe there's more benefit than that, i.e. memory protection.

Chrome already gives the least attack surface to attacker, so if SBIE adds something to it it must be hooking. OTOH Chromium developer said what brings attack surface to Chrome is mainly dlls, and often dlls are used for hooking.
However, nobody knows whether sandboxie.dll can actually be used for attacker to penetrate the system, nor SBIE can actually block an real attack which penetrated Chrome.
Penetrating Chrome is really hard task, even the man who did that task in Pwn2Own admitted it was really hard, and in that case he need a help of kernel exploit. If we hear about real attack which escapes Chrome sandbox in the future, I'm sure it is in a targeted attack and once published it will gather much attention.

IMO whether running Chrome alone or with SBIE supervision should be determined by other aspects such as downloaded executables, documents, and/or privacy.
In my case other solution care about them so I use Chrome alone. It's just my choice and I never recommend everyone to do same.

CWS, please don't just pick up a parts or passage from what any member said, but understand as a whole. Understand it along with context.
Also please stop asking absolute answer and start to learn how Chrome, SBIE, or Windows works one by one. This will take a certain period (possibly years), but eventually you'll be able to conclude your own answer. In the end, only you can convince you.

Really sorry for impertinent saying.

 

Same as some other member, I don't like to see too.
I never understand why people keep asking 'add this, implement that' for not-directly-related features for many great-by-itself products and making them bloat.
I always like simple solution, and IMO SBIE is almost completed for its job, though some compatibility issue should be addressed.
If you really want such feature, try Buster Sandbox Analyzer that is very good for easy-analysis of malware.
But keep in mind that of course it can't analyze sandbox-aware malware.

 

I am not sure Yuki but perhaps this is the post by Curt that you like to read.

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

Bo

 

Thanks Bo for the link!
So now it turned out that SBIE actually uses kernel hook for enhanced security.
Then still the same will-never-be-solved question persist about attack surface vs benefit, but I don't dig in unless needed.

Only 2 thing I currently want SBIE dev to address are that explorer issue and error message about Norton component when I use Chrome 64bit, but even those are not necessary because for some reason I'll switch my security setup soon (including removal of Norton).
I'll see whether explorer issue persist in new setup.

 

So, you see, bypassing Chrome, which uses user-mode hooks is not that hard at all, since it does not have kernel mode driver at all-so the whole idea of the increased attack surface is not worthy to be mentioned in the first place.

 

You misunderstand.
Yes, generally speaking user-mode hook have been bypassed.
But it doesn't mean kenrel-mode hook is bullet proof, and remember what Bromium showed in their study.
They claimed using kernel-mode driver can increase attack surface toward kernel exploit, and sandbox program itself also can have vulnerability.
If you search for vulnerability in AV, you'll find many of them involves its driver.
Though those exploits are usually done on local only, SBIE can be affected by such exploit as it allows malicious program run locally.

Also remember, bypassing Chrome is not easy at all as renderer process is strictly restricted before it is compromised.
Within such restriction, bypassing Chrome's hook (supervision by broker) is quite hard.

 

Well, according to your previous, extremely detailed answer to me (btw, big thanks for this detailed answer), it seems that Chrome is much, much tougher than Sandboxie/it seems to me that from your last post Chrome is much, much harder to penetrate than Sandboxie4, regardless what you said about this that it's impossible to know for sure.

However, I don't believe in this, the exploit that Chrome had that Tzuk was talking about (Bo sent a link earlier in this thread) definitely proves there is a need of sandboxing Chrome. And this mystical, hypothetical increased attack surface and whatever Bromium says is simply not trustworthy and I don't believe them at all-they are trying to find some, hypothetical, mystical holes in Sandboxie (and yet it could all have been blocked by simply blocking cmd.exe for example (I remember that very well) just to sell their products to prove their products are the best-yeah, right, many of those things is simply pure exaggeration as well as that supposed increased attack surface, I have never seen it played any kind of real-world role regarding security and protection at least when it comes to Chrome and Sandboxie.

Sure, kernel-level driver can have vulnerabilities and can be exploited/bypassed, but it is much. much harder to exploit/bypass kernel-level driver, than user-mode hooks-fact, and this is why I always Sandboxie to protect Google Chrome, and it is extremely difficult and extremely complex to write/create kernel-level exploits, while writing/creating user-mode hooks is much, much easier, and since Google Chrome uses only user-mode hooks without kernel-level driver, it is much easier to bypass it/exploit than Sandboxie which uses kernel-level driver since Sandboxie gives virtualization/sandbox protection on kernel level, while Google Chrome gives virtualization/sandbox protection only on user-mode level, which is far easier to exploit (and that's why there are so many potential CVEs).

 

I think what Bromium did to produce the results they wanted showed a lot....about Bromium themselves.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=19163#p103163

Bo

 

The explorer issue that you experience its probably related to something specific in your computer or a program in your PC that is conflicting with Sandboxie. Norton addons cause issues for many SBIE users so getting rid of it or at least not using the addons is a good idea.

Bo

 

142395 is referencing this study.

 

Exactly, agreed on all accounts, it's extremely difficult to write/create kernel-level exploits.