Version 3.55.01 introduces kernel-mode protection for 64-bit Windows. With the new Experimental Protection mode enabled, 64-bit Sandboxie is effectively as secure as 32-bit Sandboxie with only a couple of small differences.

Experimental Protection enables protection from kernel mode for IPC objects and named named pipes, just like in 32-bit Sandboxie.

To enable Experimental Protection, open the Configure menu in Sandboxie and select the new option, then restart your computer.

Note that Experimental Protection uses an undocumented Windows feature, and as such may be rendered obsolete by some future update to the Windows Kernel Patch Protection mechanism. Such a possible update might cause system instability and BSODs, so enable this new feature at your own risk.

Differences between 64-bit Experimental Protection and 32-bit Protection:

1. There is no kernel mode protection for use of the EndTask API to terminate processes outside the sandbox.

2. There is no kernel mode protection that can prevent malware setting the password for a user account which does not have a password set.

3. There is no kernel mode protection that can prevent a program from writing event messages to the Windows logs.

Note that Sandboxie does offer user mode protection for all these things, in this version as well as past versions. However, it must be noted that user mode protection is weaker than kernel mode.

All in all, these are trivial differences and I think it is safe to say that with Experimental Protection enabled, 64-bit Sandboxie can now offer 99% of the security of 32-bit Sandboxie.

Edit:

One more detail I should mention about the differences. Where the 32-bit version is able to completely deny access to a resource, where necessary, the 64-bit version cannot do this. The 64-bit version can still prevent mis-use of the resource, but to be extra sure, the 64-bit version will immediately terminate any program that is misbehaving and issue a message - SBIE2314 Canceling process.

I would like to take this opportunity to thank a few people who helped test pre-release builds of Sandboxie 3.55.01 and were able to confirm that, at this time, the new 64-bit Experimental Protection does not conflict with Kernel Patch Protection on 64-bit Windows.

Thank you Mike, Ruhe, SnDPhoenix, and soccerfan.

A final note is that with 64-bit Experimental Protection in effect, there is no longer any need to rely on the Drop Rights feature. In version 3.55.01, Sandboxie still enables Drop Rights by default on 64-bit Windows, but I plan to change this behavior in version 3.55.02, when 64-bit Experimental Protection is enabled.

Great work, I think the three drawbacks you mentioned aren't a problem at all since they can hardly be used to do any real harm to the system nor to compromise it.
Again, your information policy is exemplary!

Now, let my fulfil my uncomfortable role and let me ask you a question that is most likely of great interest for many Sandboxie users:
Do you think Microsoft has any reason to patch Patchguard again "against" this option?

I don't know what motivates them to tighten PatchGuard so I can't say anything about their reasons. I really hope they leave it as it is. In fact I hope they make it official and supported behavior! I would very much like to drop the "experimental" label and offer this as standard protection.

As a layman I'd say they would tighten it if they come to the conclusion that the way you found can be used by malware to bypass Patchguard.

Do you think (unsigned) malware could ever use the way Sandboxie uses now?
Since TDSS for x64 the whole security architecture on x64 seems a bit absurd to me, there can be rootkits active although Patchguard is enabled by just killing driver signing enforcement via MBR. *sigh*
In my humble opinion there are no good reasons to kill this great approach.


Maybe you should start working for Microsoft to have influence on this.
Just kidding.

Seriously, they could need some more open minded personal for such decisions...

Haha I was getting ready to ask about this but you've already answered my question.
Anyways, I'm glad to see you list the few differences between 32-bit and 64-bit Sandboxie now. I wanted to know what they were when I PMed you, but decided not to bother you about it since I took your word for it that they were just minor issues.

Anyways, my only remaining question really, is that in the future will Sandboxie automatically enable this experimental support (provided it's not causing issues for people) by default, or will you always have to go into the "Configure" menu to enable it?

Just want to say that although I don't currently run any 64-bit systems (and don't intend to for at least a couple more years), this is really good news. Your dedication and hard work to Sandboxie is superb - keep it up tzuk!

Julian: No, I don't think the undocumented feature I use represents any kind of vulnerability, so again, I hope it remains useful in the future.

SnD: As I implied in an earlier comment to Julian, as long as this is not an official feature, and as long as there is the threat of an update to PatchGuard starting to BSOD systems because it sees this feature used, then I will leave this feature as "opt-in" as it is today.

ssj100: Thanks!

Oh ok, understood!

In the future, is the Drop Rights feature going to always be disabled, or only if/when the user enables the experimental support?

no need for 32bit users to update to 3.55?

I am exhilarated right now, my happiness cannot be described. This news has made not just my day ,but my year! I knew you had it in you Tzuk; the will, the perseverance and the pursuit and attainment of perfection. Tzuk you are a genius made from pure win!

This exceeds anything that was ever available before like the forced user feature. Your honesty in even willing to disclose the limitations as they were, was a very brave, direct commendable approach. Your innovation is astounding. At first this seemed like an insurmountable barrier, but you did it. Congrats man and God Bless.

I would say that malware coders choose the path of least resistance. Since MBR patching achieves the goal of unsigned driver installation, using IPC access at the kernel level would definitely be less beneificial for them for the intended purpose of putting their foot in the door at the kernel level. In the future they'll just use this already tried and true method instead of trying to pass thru loopholes in KPP.

-- Tzuk if I'm wrong plz correct me because I don't want to be a source of unreliable info. --

Looks like I'm a little late to the party (as usual) but nice job tzuk! Glad to see the big leap forward in this release, and also the nice explanation of its benefits.


Awesome.