[.06] Could not execute SandboxieRpcSs.exe

[tzuk]

Version 4.01.06 turns the "I'm a sandbox, don't apply SRP/AppLocker rules on me" flag for programs running in the sandbox.

I'm afraid this is the only possible solution as SRP/AppLocker uses the security context of the process in its security checks, and in Sandboxie v4, this security context is very limited and will fail all security checks.

[DR_LaRRY_PEpPeR]

That post made me panic a bit , so I immediately downloaded and installed .06 in a fit of rage the other day.

Can you explain/clarify what you mean by "I'm a sandbox, don't apply ..." flag? What's that? (Hope it's not what I'm thinking of with "SANDBOX"...)

I checked and observed no differences on XP or 64-bit 7 HP as far as [manually configured] SRP (path rules) blocking stuff: both programs and DLLs. Nothing seems to have changed for SRP, and everything still seems to function correctly and as I'd expect. Since this has seemed correct since the first 4.01 beta, I sure hope SRP stuff stays like this!


Now, did you mean to only say AppLocker...? I wouldn't call anything SRP does (all in a process) using the "security context of the process in its security checks," so maybe you've just changed something for the more kernel-mode AppLocker... While I guess that's unfortunate for them (higher Windows edition for the "better" AppLocker), if that's what has to be done, obviously better that it only affects AppLocker and allows SRP to still function as expected.

Unless you are checking that the edition of Windows (can that be checked...?) has AppLocker available/enabled, and then SRP is disabled as well... That would be really unfortunate for users of those editions!

I could check SRP in VirtualBox with an Enterprise edition and/or try to set up AppLocker... But figured I'd see if I could get any more info first.

[fanish]

I had some AppLocker rules allowing execution in a sandbox folder, by hash rules. I deleted them, but I wasn't able to execute the program anymore. I suppose this implementation isn't working as expected. Maybe because the program was/is already installed in the sandbox? It did work as expected with newest apps installed in the sandboxes, though.

Is a bit of a concern what was implemented, though. As mentioned, I was allowing execution by hash rule, because I'm dealing with way too many executable to create access rules in the sandbox settings. The execution of any process inside that sandbox would be allowed (it would be a pain in my neck to create access rules to all those *.exes and *.ddls in the settings; AppLocker is a much faster solution).

[tzuk]

I am sorry fanish but I don't follow what you are trying to say.
Do you still see errors from Sandboxie about executing SandboxieRpcSs even with version 4.01.06 ?

[fanish]

I am sorry fanish but I don't follow what you are trying to say.
Do you still see errors from Sandboxie about executing SandboxieRpcSs even with version 4.01.06 ?

No, I don't see those errors. But, from what you mentioned in your other post, it made me believe that AppLocker wouldn't prevent execution from the sandboxes folders any longer? I cannot execute an application I had previously installed in a sandbox; I had to reenable the AppLocker rules again to be able to execute it.

Maybe I misunderstood the previous post.

[tzuk]

I think what I wrote above does not apply to your use case. Sorry about the confusion. Let me try to clarify.

What I wrote earlier only applies to program A in the sandbox trying to start program B. For example Start.exe in the sandbox trying to start SandboxieRpcSs.exe. Or IExplore.exe in the sandbox trying to start SandboxieRpcSs.exe. In this case program A can ask AppLocker to not bother with program B.

What you have here is Explorer.exe starting a forced program (either forced by name, or folder, or forced due to being in the sandbox folder). In this case Sandboxie can not yet affect AppLocker, so AppLocker rules should apply. And of course this applies to any program outside the sandbox that is starting a program in the sandbox -- not just Explorer.exe.

[tzuk]

Can you explain/clarify what you mean by "I'm a sandbox, don't apply ..." flag? What's that? (Hope it's not what I'm thinking of with "SANDBOX"...)

Sorry, I missed your post earlier. If you mean SANDBOX_INERT, that's correct and that's all I changed.

[barny]

Version 4.01.06 turns the "I'm a sandbox, don't apply SRP/AppLocker rules on me" flag for programs running in the sandbox.

I'm afraid this is the only possible solution as SRP/AppLocker uses the security context of the process in its security checks, and in Sandboxie v4, this security context is very limited and will fail all security checks.

4.01.06 now works without problem when AppLocker is enabled. Thanks tzuk!

[Sadeghi85]

Hi

I use default AppLocker rules. "Run As UAC Administrator" doesn't bypass AppLocker rules in v4.01.06, it doesn't prompt for elevation.
With or without "Run As UAC Administrator" setting, it gives this error: image

[fanish]

Hi

I use default AppLocker rules. "Run As UAC Administrator" doesn't bypass AppLocker rules in v4.01.06, it doesn't prompt for elevation.
With or without "Run As UAC Administrator" setting, it gives this error: image

Does the executable in question have an UAC icon? That would mean it has an embedded manifest file saying it needs administrator privileges. If it doesn't have it, then that's why you're seeing that error message. I also experienced it with executables lacking that UAC icon/manifest.

Can you confirm that it also happens with other files that don't have the manifest (lacks the UAC icon)?

@ tzuk

Thank you for clarifying it. It makes me wonder about something, though. Sometime ago Microsoft released an hotfix for the SANDBOX_INERT "bypass". -http://support.microsoft.com/kb/2532445

I got that hotfix applied, but clearly what you did to Sandboxie made the errors go away. Shouldn't AppLocker + Hotfix prevent it (program A from starting program B)? Strange stuff. lol

[Sadeghi85]

Can you confirm that it also happens with other files that don't have the manifest (lacks the UAC icon)?

This is what I discovered:

v4.01.06:

1. If the executable has manifest, it prompts for elevation, no need for "Run As UAC Administrator" setting.
2. If it doesn't have manifest, it gets blocked, "Run As UAC Administrator" setting doesn't help either.

v3.76:

1. If the executable has manifest, it prompts for elevation, no need for "Run As UAC Administrator" setting.
2. If it doesn't have manifest, it gets blocked, BUT "Run As UAC Administrator" setting prompts for elevation.

[DR_LaRRY_PEpPeR]

Sorry, I missed your post earlier. If you mean SANDBOX_INERT, that's correct and that's all I changed.

OK, yeah, and I meant for Sandboxie's sake, rather than mine (that you didn't mean that), because of the AppLocker fix fanish posted. I assume you know about that...? Perhaps it's not an issue, however (behavior fanish reports), because if this is the SbieSvc program we're talking about, that SYSTEM process can still use SANDBOX_INERT even with the AppLocker fix installed. But... (see below)

What I wrote earlier only applies to program A in the sandbox trying to start program B. For example Start.exe in the sandbox trying to start SandboxieRpcSs.exe. Or IExplore.exe in the sandbox trying to start SandboxieRpcSs.exe. In this case program A can ask AppLocker to not bother with program B.

Is this only when the "target" is SandboxieRpcSs that the changes apply.....?? And one of the recent changes is that RpcSs is now launched by SbieSvc... And stuff running as SYSTEM is already supposed to ignore SRP, but I guess that part (SYSTEM being excluded from restrictions) does not apply to AppLocker, is that right...? *shrug*


Because like I said, I can't find a scenario, from in or out of the sandbox, programs or DLLs, where SRP is being ignored, which is good and as 4.01 has been. Just trying to fully understand where/how the change is applied (just RpcSs?).

Is the SANDBOX_INERT flag used on all platforms unconditionally, or just on editions where AppLocker is available or active?

[tzuk]

That sandbox inert flag is enabled by kernel mode code so I don't think that KB update makes a difference. I mean, evidently it works, right?..

The flag is enabled for all processes in the sandbox regardless of version or edition of Windows.

Finally:

I use default AppLocker rules. "Run As UAC Administrator" doesn't bypass AppLocker rules in v4.01.06, it doesn't prompt for elevation. With or without "Run As UAC Administrator" setting, it gives this error:

I don't see the error. On my end I see that with or without the "Run As UAC Administrator" setting, it starts the program the same: No error from AppLocker, and no elevation either.

I fixed the "Run As UAC Administrator" setting, which is not related to AppLocker, and looks like it wasn't working in any version 4 release so far.

[fanish]

That sandbox inert flag is enabled by kernel mode code so I don't think that KB update makes a difference. I mean, evidently it works, right?..

The flag is enabled for all processes in the sandbox regardless of version or edition of Windows.

Evidently, what you did is working. But, according to security researcher Didier Stevens, the actions his PoC performs were blocked by AppLocker, once he applied the patch. See: hxxp://blog.didierstevens.com/2011/11/17/hotfix-for-srpapplocker-bypass/

There's a comment by him where he states it.

Everything is so odd, indeed. So, apparently this hotfix is nothing but placebo?

Can anyone compile this code in his blog and see what happens?

Code is here hxxp://blog.didierstevens.com/2011/01/25/circumventing-srp-and-applocker-to-create-a-new-process-by-design/

It would, for sure, be interesting to see what results you'll find.

[tzuk]

Ah, so this KB isn't actually a mandatory update. I assumed the update was already installed (on your systems and mine) so that if turning the sandbox inert flag works then evidently it works with this KB applied. Which I now understand was an incorrect assumption.

So then it is possible I guess that having this KB would break this AppLocker fix in Sandboxie. In that case I don't think I would be able to find another solution to the problem. On the other hand it is possible the KB would not interfere with kernel mode code that turns on this bit.