Sandboxie 64 alternative?

If you are really worried, that would probably give you extra protection (Peter2150, uses Sandboxie and Shadow Defender when testing malware). I have ShadowUser Pro on one computer which is vulnerable to some of Subset's malware samples (KillDisk and KillMBR), in 5 years of continuous use and lately by my wife, no malware has ever been detected by powerful scanners like Malwarebyte and ASquared; not to mention the fact that most malware which specifically attack sanboxes and virtualizers, are easily detected by most AVs.

No recommendation can match your own judgement about your needs and habits. TheIgster https://www.wilderssecurity.com/showthread.php?t=265873 has been using Shadow Defender on a Windows 7 -64bit to return his system to a clean state (after testing 'brand new' malware). So far he had no problems, but to be 100% safe imaging your system is absolutely necessary IMO.

 

Excellent post! Hopefully others will read it again and realize that Tzuk has been honest about the 64bit OS limitations. Unfortunately his honesty has ended up hurting him.

 

+1
Unfortunately Tzuk has now scaled back the warning. I had read his FAQ earlier (before he started releasinig 64 bit sandboxie again), and he basically said that sandboxie would be useless in 64 bit systems due to patchguard.

Now, there is no such clear cut warning.

EDIT: The following post sheds light on the security on the 64 bit version:
https://www.wilderssecurity.com/showpost.php?p=1613569&postcount=13

 

why not use the one in Avast AV or Suite. I have tested in 64 bit with no issues.

 

As Tzuk said, the 64 bit limitation is an inherent feature of 64 bit windows. It does not matter which software you use, they will be similarly hindered to Sandboxie. Sandboxie is just honest about it.

 

I respectfully disagree. Each vendor will tackle this issue differently.

 

Each vendor will tackle this issue..the way MS lets them do it...or not do it.

 

For X64,

Run LUA = low rights processes and objects can not touch higher rights objects

Use Iron or download Chrome from Google Pack = has internal sandbox and runs with lowest rights.

Buy AppGuard x64 to prevent side by side intrusions (same rights objects are allowed to touch each other, new memory guard prevents this)

Regards Kees

 

Is true when for sandbox layers outside the threatgate applications (e.g. Webbrowser and mail protected by Sandboxie).

Chrome is able to prevent side by side intrusions of one sandboxed tab by another. So when the sandbox resides inside the threatgate application it can be done (Chrome's internal sandbox containing tabs individually).

 

Kees, I realized a thread on the sbie forums asking Tzuk about side by side infection or same object rights infection; http://www.sandboxie.com/phpbb/viewtopic.php?t=8708
for some reason Tzuk wasnt very helpful in explaining how it can be done elsewhere and what are the limitations...

 

With the set Microsoft provided for third parties, there are limitations, depending on the design philosophy of the security program.

For HIPS, Policy Management and Application virtualisation it is correct what Tzuk has explained.

Programs with a different design philosophy (e.g. Returnil, PrevX) are build on different principles, like Returnil redirects all changes to the system partition. Returnil has sufficient means to implement it design philosophy (only looking at disk access).

PrevX can handle the limitation with the Microsoft provided set because it does behaviour analysis, black and white listing. Let me explain. Process A calls service B. This call is handled by the OS. PrevX can intercept the obvious mechanism (like SBIE). Problem only is that a malware can use a two step diversion to finally get access to service B. These two consequetive steps are so extra ordinary, that PrevX signals Process A as suspicious. It checks its white and blacklist and sends process A's binary to its servers in the cloud for analysis when it is not in both. As soon as Process A does another suspicious thing PrevX wll warn the user. The programmers of PrevX are also not able to prevent this access. Only due to its suspicious behaviour they have found enough circumstantial evidence to flag it as highly suspicious. With a bit of luck the user decides to deny and kill the process. Hopefully when a next victim is faced with this malware, PrevX has analysed the malware's binary and added it to the blacklist.

Now have a loook at chrome. Picture the chrome process as the Parent process (with medium rights = lua). It runs it tabs in seperate child processes (child1 with low level rights = protected mode, child2 in another tab). The protected mode in itself provides protection to all objects running high and medium rights. Another trick Chrome does is that it does not interpretate Javascript, but compiles it and does some magic with shared libraries (so child proces1 can not touch something located elsewhere in the library used by child2). Chrome compiles the Javascript and filters out calls to the OS. So the compiled Javascript not only is faster, but it does not call to the OS, instead it calls to the Parent process. In this way Chrome evades the limitations set by the Microsoft and can set its own limitations on this call.

Hope this helps (and the explanation is simplified).

To resume
a) Virtual Machines can do their job
b) Partition virtualisation programs can do their job
c) Behavioral blockers can do their job
d) Browser with internal sandboxes can achieve this (but will still have a problem with unsandboxed plug-ins, like flash, pdf)

All others who claim to provide full protection are simply lying (on x64 that is)

When you sandbox Chrome with SBIE on x64, I can't imagine a malware coming through. So we are talking of theoretical weaknesses (chrome compensates SBIE service issue, SBIE compensates Chrome's plug-in issue).

I also feel that Tzuk's honesty back fires on SBIE (while other FW/HIPS pretend to provide the perfect protection).

Regards Kees

 

This is largely correct, but it might be worth a bit of clarification. Sandboxie, because of its goals of isolation, has to be 100% perfect for it to really work and it (intentionally) only monitors what it is currently sandboxing. However, in Prevx's case and the case of other non-sandbox-oriented security products, we are looking at the system as a whole and can therefore infer intent.

These discussions generally try to stay high level but I think it would be worth giving a specific example here to help explain the issues. When creating a service on the system using "standard" methods, the service creation functions send a message to another process on the system which then actually modifies the system and adds the service registry entries, etc. Microsoft does not offer an interface to hook this type of message transmission but because of how Prevx sits on the system, it can see both ends of the equation and tie them back together. There are high-level ways of blocking service creation before the message is even sent... but unfortunately they can be bypassed quite easily.

Sandboxie is honestly a great product and if it was to fully use all of the documented interfaces (which it very well might be doing - I haven't looked at it on the technical side close enough) on x64, it could cover upwards of 98% of cases. It is the last 2% where issues come but unfortunately in the case of any sandbox, users will rely on it and its ability to perfectly isolate running applications.

There are ways around this (I mentioned one several months ago in another thread, but there are others as well) but they would require quite a lot of development effort to try to bridge the gap, however, it is possible

And to clear the air: Prevx is not currently developing a competing sandbox. Prevx 4 will have some sandbox-esque features but we are not trying to compete with Sandboxie

 

Mike (Coldmoon of Returnil) send me a PM to confirm that Returnil has no problems providing the same level of security in a 64 bit environment, because Returnil works at the disk filter level rather than the higher filter system level.

Mike is allways very hesitant in commenting in other Vendors threads. But since I am the cause of it, I hope Wilders Members won't mind PrevxHelp providing background info.

As said I simplified the explanation and am quite sure when SBIE users combine SBIE with for instance Iron (or Chrome from Google pack) the two 98% coverages together will provide 99,9999999999999% protection (only because 100% is unreachable).

Cheers Kees

 

I don't necessarily agree that a test against 10 malware is automatically irrelevant.A lot depends on which 10 malware are chosen for the test.

If you choose 10 that utilize 10 prevalent infection mechanisms used by current malware in the wild,then you get an overview of how a product copes with the infection methodology of a high proportion of active threats,given that the bulk of malware at any particular time are just variants of a relatively small number of families;far more relevant than mere numbers IMO.

 

Ohhh one hasty correction before I get eternally cursed by Rmus and Windchild.

 

Thank you Kees for your explanation its very helpful indeed . I believe it should be cloned to the x64 security sticky on this forum as to what security mechanisms are effective on this new platform.

PrevxHelp could you please link me to that thread? Could you maybe communicate those ideas to Tzuk someway? I appreciate your feedback.

 

Tzuk was responding in the thread as well https://www.wilderssecurity.com/showthread.php?t=250126 (https://www.wilderssecurity.com/showpost.php?p=1520707&postcount=94)

 

Are you hinting to use Local Procedure Calls to intercept the messages created by the service?

 

The largest hole in x64 protection is LPC - but indeed, it is still calling a procedure, which can be secured on the destination end

 

To Tzuk, PrevXHelp and Ilya


Would not be an option to achieve this the way Chrome does?

Using the CreateRestrictedtoken API and AdjustTokenPrivileges to lock down the token the rendering process (=this would be the aps in the untrusted list for SBIE and DW) is running with.

Using a Job object to place limitations on what the rendering process (again the untrusted processes **)can do

Running the rendering process on a separate desktop to prevent window message abuse


** may be x64 version should have some application monitor which intercepts the launch of applications on the untrusted list/sandbox list

Anyway just my 2 cents, see (see https://code.google.com/p/ulimitnt/wiki/Readme)

 

So the 64 bit version of Sandboxie does NOT have restrictions on running and internet privileges? Also the testing of malware on the 32 bit version and people saying its getting through. Is this plain vanilla Sandboxie or with some settings tweaked such as internet/running rights?

 

Is there an alternative for XP-64 on which Sandboxie does not run at all?

 

Maybe I'm being simplistic but wouldn't Patchguard stop anything that tries to change the kernel like a rootkit? If that's true, then wouldn't Sandboxie take care of all the rest?

 

Does the kernel need to be changed to install, say a keylogger?

Even if yes, with root privileges, a program could run and infect firefox, so that your passwords are intercepted in firefox.....

 

I don't know enough to answer that but if the kernel is protected against change, then a good malware scanner would eliminate keyloggers and if only the browser is sandboxed, then nothing else can get in to steal passwords.