Sandboxie Forum - Experimental Protection [64-bit] (10201)

Mike:

Mon Apr 18, 2011 12:10 am

Welcome, new guy. You know, after [url=http://www.sandboxie.com/phpbb/viewtopic.php?p=66707#66707]last time[/url], I was going to register as D1G1T@L just to mess with you.

D1G1T@L:

Sun Apr 17, 2011 11:47 pm

]]>Quoting tzuk: ]]>I'll redact your posts on the condition that you create a forum account so stuff like this doesn't happen again. ]]> :oops: Aight sounds good.

D1G1T@L-guestt:

Sun Apr 17, 2011 9:31 pm

@ Buster: I lol'd hard

Buster:

Sun Apr 17, 2011 2:50 pm

]]>Quoting D1G1T@L: ]]>I'll take the advice in this pic: [img]farm4.static.flickr.com/3217/3015062728_6b27f9a6ae.jpg[/img] ]]> [img:5632e15d2d]http://img716.imageshack.us/img716/7590/aaa2.gif[/img:5632e15d2d] Cats: the best friends of forum users. :wink:

D1G1T@L:

Sat Apr 16, 2011 7:22 pm

I'll take the advice in this pic: [img]farm4.static.flickr.com/3217/3015062728_6b27f9a6ae.jpg[/img]

tzuk:

Sat Apr 16, 2011 5:36 pm

I think I already said all I have to say about EndTask.

Guest10:

Fri Apr 15, 2011 10:43 pm

]]>Quoting D1G1T@L: ]]> ]]>Quoting tzuk: ]]>Supervising this at the kernel level is not possible on 64-bit Windows, except perhaps by messing with the system csrss.exe processes, which would then cause other security software to rightly say that Sandboxie is a saboteur. ]]>If AVs detect FPs we could clear them up quickly like the ones that happened recently. If after trying this and seeing that it won't work by design please say how. ]]>Once Sandboxie was labeled as a "saboteur", it might be hard to restore the program's reputation. Why would any responsible programmer risk his work like that?

blasev:

Wed Apr 13, 2011 5:15 am

I can confirmed that new windows update didn't cause any BSOD while using SBIE 3.55.03 on W7 64bit

IncomingPatches:

Tue Apr 12, 2011 6:53 pm

The next round of Windows updates coming this month (today or tomorrow) will involve patching of the kernel to close up some known security holes. More information can be found [url=http://www.computerworld.com/s/article/9215640/Patch_Tuesday_focus_Big_bunch_of_Windows_kernel_bugs_]on this webpage[/url] [quote:e26b7f15b3]On Thursday, Microsoft announced that next week's monthly security update will feature a record-tying 17 bulletins that patch a record 64 vulnerabilities, 15 more than the previous largest-ever set in October 2010. While Microsoft does not reveal much information about the upcoming updates in its advance notifications, the sheer number of critical bulletins that affect Windows -- nine altogether, more than half the total -- likely means that at least one affects the kernel, said Andrew Storms, director of security operations at nCircle Security. "Although there's not enough to go on from the advance notification, I think one or more kernel patches is a pretty darn good possibility," said Storms. "They've had their problems with the kernel lately."[/quote:e26b7f15b3] I'm not an expert user. Will this impact the new security feature of Sandboxie? I can imagine that, at best, this might render the new security feature inoperable. At worst, if Microsoft tweaks PatchGuard, if could cause systems running the new security feature of Sandboxie to BSOD on startup.

blasev:

Tue Apr 12, 2011 1:08 pm

]]>Quoting blasev: ]]> Does that explain why firefox 4 keep on crashing while using 3.55.02? I use win 7 64bit btw Hopefully the problem will be gone with 3.55.03 :) ]]> yup the problem is gone with 3.55.03

blasev:

Mon Apr 11, 2011 11:14 pm

]]>Quoting tzuk: ]]>If this does happen then the program must have messed with the protection at the application level. (The exception of course is when the new kernel protection is still new and a bit buggy, and wrongly terminates programs in some cases.) ]]> Does that explain why firefox 4 keep on crashing while using 3.55.02? I use win 7 64bit btw Hopefully the problem will be gone with 3.55.03 :)

tzuk:

Mon Apr 11, 2011 9:53 pm

]]>Quoting D1G1T@L: ]]>Tzuk I thought you'd move the posts either way nvm now ]]> :P To answer your (plural) questions about program termination. There is a protection layer at the application level and there is a protection level on the kernel level. Normally a program never reaches the kernel level with a request that Sandboxie would have to block. If this does happen then the program must have messed with the protection at the application level. (The exception of course is when the new kernel protection is still new and a bit buggy, and wrongly terminates programs in some cases.) Now on 32-bit Windows, even if a program can bypass the protection at the application level, Sandboxie is able to completely prevent the program from accessing the resource. On 64-bit Windows, Sandboxie cannot completely prevent the program from accessing the resource, it can only tell Windows to not let the program do anything with the resource. This is a fine distinction which probably makes zero difference in practical terms. But again the program is never supposed to be in this situation unless something wrong happened to the protection at the application level. Therefore I feel it is reasonable to terminate the program at this point. As for EndTask, this is not a standalone resource in the system that you can allow or deny access to. It is one of many possible requests on a main channel between a program and the CSRSS process. In other words it is a sequence of bytes going into one end of some communication channel, and causing CSRSS to end programs. It is not possible to supervise what goes into this channel, as with other necessary things, there are no supported kernel interfaces for doing something like this. So hopefully this finally clarifies everything for everyone.

D1G1T@L:

Mon Apr 11, 2011 9:02 pm

Alright so I will repost this here for informational purposes to add info that might anwser other similar future questions. Tzuk I thought you'd move the posts either way nvm now :) ]]>Quoting SnDPhoenix: ]]> Hmm, ok, so it seems Sandboxie is too sensitive right now as it's terminating simple installers. May I ask though, whats the point in terminating a process that's trying to access/mis-use a particular resource? If Sandboxie is able to prevent a program from abusing some resource, then whats the problem? Why not just let Sandboxie handle the programs access/use of some particular resource, instead of just outright terminating the process, what does that achieve? P.S. A quick question. If x64 Sandboxie is unable to deny programs from accessing resources, then how come denying programs access to the internet still works? ]]> My reply: ]]>Quoting Me: ]]>Sandboxie relies on closed file paths to deny programs internet access rather than use closed IPC paths. Thats why in this case the Kernel would support actual blocking of file access, but in the case of IPC, according to Tzuk this can't be accomplished so instead the process is blocked from running so it can't misuse the potentially poweful resource. Thats a very smart approach if you think about it an excellent way to make ends meet. ]]> So just for the sake of discussion, are things like internet access/ ports and the EndTask API (mentioned many times already) not reliant on IPC?

tzuk:

Sat Apr 09, 2011 5:56 pm

Yeah, I didn't get around to addressing that Drop Rights thing yet. Still planning to take care of it though.

SnDPhoenix:

Sat Apr 09, 2011 5:19 pm

]]>Quoting Mike: ]]>when I create a new sandbox, Drop Rights is still enabled by default. ]]> Yep, I noticed this myself. :P

Mike:

Sat Apr 09, 2011 4:57 pm

]]>Quoting tzuk: ]]>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. ]]> Maybe you haven't gotten around to this yet, but I have experimental protection enabled on 3.55.02 and when I create a new sandbox, Drop Rights is still enabled by default. ]]>Quoting wraithdu: ]]>And if you want to be really slick, then try THIS. I schedule the script to run this way though ... ]]> Good tip. Very slick.

Julian:

Sat Apr 09, 2011 1:00 pm

]]>Quoting KBFloYd: ]]>Ok thanks for the reply. One last thing I want to know, in this case could Endtask be used to shutdown or crash the system deliberately? ]]> I don't think so, at least Matousec kill5 can only kill processes with a window. Unlikely to happen.

KBFloYd:

Fri Apr 08, 2011 4:15 pm

Ok thanks for the reply. One last thing I want to know, in this case could Endtask be used to shutdown or crash the system deliberately?

mossman:

Fri Apr 08, 2011 7:20 am

Seems to be running OK on Vista 64-bit. I am more than happy with the extra protection provided.

tzuk:

Thu Apr 07, 2011 12:57 am

I see there is some interest in the EndTask thing. As I said Sandboxie does what it can by supervising this at the user mode / application level. Supervising this at the kernel level is not possible on 64-bit Windows, except perhaps by messing with the system csrss.exe processes, which would then cause other security software to rightly say that Sandboxie is a saboteur. Other than that I refer you to D1G1T@L's closing statement of an earlier post in this topic.

wraithdu:

Wed Apr 06, 2011 11:52 pm

Easier to just use [url=http://technet.microsoft.com/en-us/sysinternals/bb963905]Autologon from Sysinternals[/url]. Edit: And if you want to be really slick, then try [url=http://mblog.lib.umich.edu/~awilkins/archives/2006/10/automatically_l.html]THIS[/url]. I schedule the script to run this way though - 1) open Group Policy Editor (gpedit.msc) 2) User Configuration -> Windows Settings -> Scripts (Logon/Logoff) 3) Open Logon and add your script

Mike:

Wed Apr 06, 2011 8:33 pm

]]>Quoting DuckTales: ]]>My admin account that I use all the time (got no other account on the computer) got no password, does this mean a virus can lock me off from my own computer by setting a password? (I'm not using a password because I want my computer to boot faster by login in right away) ]]> I'm not qualified to answer your question directly, but here's a suggestion. Set a password, which is good practice anyway, and then enable [url=http://channel9.msdn.com/Blogs/coolstuff/Tip-Auto-Login-Your-Windows-7-User-Account]auto-login[/url].

KBFloYd:

Wed Apr 06, 2011 3:21 pm

]]>Quoting tzuk: ]]> 1. There is no kernel mode protection for use of the EndTask API to terminate processes outside the sandbox. ]]> ]]>Quoting _Harry_: ]]>Excellent work indeed. I thought that was an April fools joke someone posted on another forum, but luckily its true! I think that the very small differences are not a big deal at all. If its possible to know when an EndTask API call is directed to an unsandboxed process, maybe Sbie could also cancel anything that attempts to do this instead of blocking this request directly since thats not supported. ]]> Could this work? If not, can tzuk or anyone please explain why. I have no idea how to code so I'm asking. Just curious thats all.

Mike:

Wed Apr 06, 2011 2:48 pm

@D1G1T@L: Oh well, thanks for the reply. With [url=http://www.microsoft.com/presspass/press/2011/jan11/01-27fy11q2earningspr.mspx]over 300 million[/url] Windows 7 licenses sold, I don't imagine they're too concerned about a few Sandboxie users.

Ruhe:

Wed Apr 06, 2011 12:53 pm

]]>Quoting n1: ]]>is the user left free to choose whether to use this feature or not, am i wrong? ]]> The user can enable or disable it.

n1:

Wed Apr 06, 2011 12:27 pm

[quote:d5d50d5f81]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.[/quote:d5d50d5f81] is the user left free to choose whether to use this feature or not, am i wrong?

DuckTales:

Wed Apr 06, 2011 10:20 am

]]>Quoting tzuk: ]]>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. ]]>My admin account that I use all the time (got no other account on the computer) got no password, does this mean a virus can lock me off from my own computer by setting a password? (I'm not using a password because I want my computer to boot faster by login in right away)

D1G1T@L:

Tue Apr 05, 2011 2:51 am

]]>Quoting Mike: ]]> Any thoughts about how to make that happen? Would it help if a hundred Sandboxie users submitted feedback to Microsoft to draw more attention to the issue? Maybe not, but just thought I'd ask. ]]> @Mike No, no need to talk to Microsoft about this, they don't care and they might try to hinder progress even more. In the past I've attempted to reason with KPPInput to cooperate with Tzuk, but all I got was a generic reply saying that the requested api "does not align with Microsoft's strategy in stopping malware execution" -- whatever the hell that means. Further correspondance with them led to lame and utterly meaningless suggestions that Tzuk should go to plugfests. At that point I understood why Tzuk was frustrated with this. Unlike what some people thought, he did try but all his requests fell on deaf ears. This reaction reveals MS' deliberate strategy of kneecapping security vendors and any effective security software out there for their own benefit ,because they have now entered this industry. @ Harry Terminating processes outside the sandbox presents no risk as Sandboxie's protection is enforeced through its driver component which remains untouched from this technique. Sandboxie's processes provide more functionality on behalf of the sandboxed programs. By terminating these processes malware still can't escape, the only thing this achieved is more reduced functionality for itself. :roll: :wink: In reality I would say Sandboxie now provides the 100% on x64. I bet if your suggestion was even possible, it would have crossed Tzuk's mind by now. I don't think that this is the way EndTask works.

Mike:

Mon Apr 04, 2011 9:30 pm

]]>Quoting tzuk: ]]>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! ]]> Any thoughts about how to make that happen? Would it help if a hundred Sandboxie users submitted feedback to Microsoft to draw more attention to the issue? Maybe not, but just thought I'd ask.

cmasd:

Sat Apr 02, 2011 8:23 pm

Great work, Tzuk. Great news and Great support to all of us with windows 7 64 bit :)

_Harry_:

Sat Apr 02, 2011 4:11 pm

Excellent work indeed. I thought that was an April fools joke someone posted on another forum, but luckily its true! I think that the very small differences are not a big deal at all. If its possible to know when an EndTask API call is directed to an unsandboxed process, maybe Sbie could also cancel anything that attempts to do this instead of blocking this request directly since thats not supported.

bo.elam:

Sat Apr 02, 2011 1:15 am

I run XP 32 bit but I am very happy about what you doing to make the 64 bit version stronger. It makes SBIE better and we, who love SBIE, can recommend it to more people. Bo

blasev: I was wrong

Fri Apr 01, 2011 2:17 pm

sometimes before I was doubting tzuk love for the 64bit version he proves that I'm wrong , and I'm glad for that :D thanks for the hard work, I'm really satisfied with the product

Ruhe:

Fri Apr 01, 2011 1:13 pm

]]>Quoting skudo: ]]>Is it alright to install 3.55 over 3.54? I have a 64 bit system ]]> I did it this way.

skokospa:

Fri Apr 01, 2011 1:09 pm

I installed sandboxie 3.55.01 and working perfectly...win7 home pro 64bit the course included experimental Protection(64bit) Thanks Mr. Ronen...you did a great job....

skudo:

Fri Apr 01, 2011 1:05 pm

Is it alright to install 3.55 over 3.54? I have a 64 bit system

eternalbeta:

Fri Apr 01, 2011 12:35 pm

I've been running 3.55.01 on Win7 Ultimate 64 bit for several ours now, trying it out in all circumstances with Outpost Security Suite 7.1, Mullvad VPN, Office 2007, Truecrypt and forced Firefox 4, Roboform 7, Outlook 2007 etc and it's running fine over here, without any glitch whatsoever in the presence of the added 64bit security, so IMHO a big leap forward in this release. Thanks a lot! :D

soccerfan:

Fri Apr 01, 2011 12:30 pm

]]>Quoting Mike: ]]>Glad to see the big leap forward in this release, and also the nice explanation of its benefits. ]]> Exactly :D After addressing software compatibility in the past few sandboxie versions, I'm glad tzuk is concentrating on tightening its security aspects (not that much needed tightening in the first place). :lol:

D1G1T@L:

Fri Apr 01, 2011 11:18 am

]]>Quoting tzuk: ]]> A bit over the top but I appreciate the senitment. Would appreciate if future praise could focus on the software and not the person. ]]> But Tzuk, you are Sandboxie :P ]]>Quoting tzuk: ]]> As for discussion about PatchGuard, I don't want to correct you and I don't want to start another discussion about PatchGuard again, least of all in this topic. ]]> Sorry didn't mean to open that old can of worms again, who cares about that anymore? :D I just meant to say that MS wouldn't have a good reason to block this approach. So happy right now.

tzuk:

Fri Apr 01, 2011 10:20 am

]]>Quoting SnDPhoenix: ]]>In the future, is the Drop Rights feature going to always be disabled, or only if/when the user enables the experimental support? ]]> I made a small comment about this, check the post at 7:45 pm. ]]>Quoting darkwolf_99: ]]>no need for 32bit users to update to 3.55? ]]> Specifically regarding 3.55 .01 , yes, that's right. ]]>Quoting D1G1T@L: ]]>I am exhilarated right now, my happiness cannot be described. ... More praise. ]]> A bit over the top but I appreciate the senitment. Would appreciate if future praise could focus on the software and not the person. As for discussion about PatchGuard, I don't want to correct you and I don't want to start another discussion about PatchGuard again, least of all in this topic. ]]>Quoting Mike: ]]>Glad to see the big leap forward in this release ]]> :)

Mike:

Fri Apr 01, 2011 3:30 am

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. ]]>Quoting D1G1T@L: ]]>I am exhilarated right now, my happiness cannot be described. This news has made not just my day ,but my year! ]]> Awesome. :)

D1G1T@L:

Fri Apr 01, 2011 1:59 am

]]>Quoting Julian: ]]> 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. ]]> 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. --

D1G1T@L:

Fri Apr 01, 2011 1:23 am

:D :D :D 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.

darkwolf_99:

Fri Apr 01, 2011 12:53 am

no need for 32bit users to update to 3.55?

SnDPhoenix:

Thu Mar 31, 2011 11:57 pm

]]>Quoting tzuk: ]]>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. ]]> 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?

tzuk:

Thu Mar 31, 2011 11:08 pm

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!

ssj100:

Thu Mar 31, 2011 10:37 pm

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!

SnDPhoenix:

Thu Mar 31, 2011 10:15 pm

]]>Quoting tzuk: ]]>with 64-bit Experimental Protection in effect, there is no longer any need to rely on the Drop Rights feature. ]]> Haha I was getting ready to ask about this but you've already answered my question. :lol: 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? :P

Julian:

Thu Mar 31, 2011 9:17 pm

]]>Quoting tzuk: ]]>I don't know what motivates them to tighten PatchGuard so I can't say anything about their reasons. ]]> 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. ]]>Quoting tzuk: ]]> 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. ]]> Maybe you should start working for Microsoft to have influence on this. Just kidding. :P Seriously, they could need some more open minded personal for such decisions...

tzuk:

Thu Mar 31, 2011 8:52 pm

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.

Julian:

Thu Mar 31, 2011 8:27 pm

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?

tzuk:

Thu Mar 31, 2011 7:45 pm

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.

tzuk:

Thu Mar 31, 2011 7:43 pm

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. :)

tzuk:

Thu Mar 31, 2011 7:40 pm

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.

tzuk: Experimental Protection [64-bit]

Thu Mar 31, 2011 7:35 pm

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.