[.06] Could not execute SandboxieRpcSs.exe

[DR_LaRRY_PEpPeR]

fanish, as I said, I also wondered about the patch like you. But look at the description of SANDBOX_INERT on the CreateRestrictedToken page. "On systems with KB2532445 installed," it says the system ignores SANDBOX_INERT unless the process is running as SYSTEM (LocalSystem).

I said how SRP, without any patch, already was not supposed to apply to SYSTEM processes, but I guess the same is not true for AppLocker...

Yes, I may be trying Didier's code soon (against my own fix, below)... or maybe NOT: to determine exactly what restrictions may not apply for sandboxed processes. I guess I'll have to run one of those 7 Enterprise VM images to play with AppLocker.


I don't quite get how tzuk says the flag is enabled by kernel-mode code (meaning SYSTEM SbieSvc I assume), but yet it's also "enabled for all processes in the sandbox," which would seem to suggest that normal, user-mode sandboxed processes could bypass restrictions, yet I don't see that with simple SRP -- that page suggests SANDBOX_INERT also applies to SRP and not only AppLocker. *shrug* Although IF AppLocker/SRP could be bypassed, having that fix installed should correct it for "normal, user-mode" processes.

BTW, I will hopefully soon create a DLL that should fix the "SRP bypass hole" on XP/Vista (8??) as well. I just need to check which lowest level functions to hook... It may be only for within Sandboxie first (if it works and is simpler), but hopefully system wide as well (or for folks without Sandboxie). Hopefully these Sandboxie changes don't screw each other up. A simple SBIE DLL I tried awhile ago to fix the LoadLibraryEx hole still works fine.

[tzuk]

I don't quite get how tzuk says the flag is enabled by kernel-mode code (meaning SYSTEM SbieSvc I assume)

I mean the driver component of Sandboxie.

[fanish]

Yes, I missed that part. It does mention LocalSystem/TrustedInstaller.

I tried another PoC (hxxp://www.mountknowledge.nl/2011/01/28/bypass ... and-excel/), based on Didider's one, and AppLocker did block it. So, the hotfix is working... for processes not running as LocalSystem/TrustedInstaller.

[DR_LaRRY_PEpPeR]

You tried it in a sandbox I assume? I'm actually curious what happens without the hotfix now. Is it hard to uninstall/reinstall? I guess it requires a restart? Oh well, if nothing else I'll wait and check myself!

[fanish]

You tried it in a sandbox I assume? I'm actually curious what happens without the hotfix now. Is it hard to uninstall/reinstall? I guess it requires a restart? Oh well, if nothing else I'll wait and check myself!

I was going to test both outside and inside of the sandbox, to see the results. But, when I ran Word.exe in the sandbox, AppLocker blocked something related to office in the user profile, and then I got BSOD.

Will have to create temp rules and see what happens.

So, the result I provided is for when I ran the PoC outside of the sandbox.

[DR_LaRRY_PEpPeR]

Wow BSOD, oops! And BTW, yeah, these Sandboxie changes should not affect AppLocker/SRP outside of the sandbox -- that would be extreme if it somehow affected everything.

[fanish]

Wow BSOD, oops! And BTW, yeah, these Sandboxie changes should not affect AppLocker/SRP outside of the sandbox -- that would be extreme if it somehow affected everything.

No, I didn't test outside the sandbox to verify whether or not Sandboxie did something outside.

According to Tzuk, he mistakenly believed the hotfix was installed already in all Windows 7 versions with AppLocker. He updated his previous post. His second assumption is correct. AppLocker's hotfix does break the fix he implemented. And, the reason I say this, comes in the line of his first assumption, that the flag SANDBOX_INERT would apply to all sandboxed processes. With this in mind, it made sense to execute of one of the apps I have in a sandbox, which does call another app. I removed the AppLocker rule for this other app, and called it from the main app. It's blocked.

Those not having the hotfix already installed, could easily test Sandboxie's fix this way. I hope that's accurate way of testing it.

[DR_LaRRY_PEpPeR]

No, I didn't test outside the sandbox to verify whether or not Sandboxie did something outside.

You didn't?

So, the result I provided is for when I ran the PoC outside of the sandbox.

But anyway, other than that, I'm not sure I follow 100% without testing myself... I'll have to get that VM image downloaded.

So I guess you did NOT try by temporarily removing the hotfix? (Since "those not having" could test...)


And you say he's right that it breaks the Sandboxie fix, yet you said previously that Sandboxie's errors are gone, even though you have the fix installed. That would suggest that it IS working still, just that perhaps the ONLY thing that needs it is either the kernel driver/SbieSvc SYSTEM process, which CAN still use SANDBOX_INERT.

Since if I understood right, you ARE still seeing something blocked as it should be in the sandbox? Of course, you have the fix installed, right, but just verifying. If so, yet Sandboxie is still working without errors in other parts that you had before, it would be nice if tzuk could ONLY use SANDBOX_INERT in the places where it's actually still having an effect, presumably (SYSTEM level), instead of on "all processes in the sandbox."

That way, people that do NOT have the AppLocker hotfix installed would still have AppLocker working in the sandbox, for the most part (short of an exploit using SANDBOX_INERT). Again, that's IF it really is disabling AppLocker, without the hotfix, for regular programs, since I don't see that happening with SRP (which SANDBOX_INERT supposedly also affects).

[Alex1992]

Good afternoon. When upgrading from a previous version 3.6 to 4. 06 there is an error starting rpcss. Used in conjunction with the BSA, and the configuration file inject_dll prescribing error occurs in the case of removal of these parameters is run without error on windows xp sp3. In what could be the problem?

[fanish]

No, I didn't test outside the sandbox to verify whether or not Sandboxie did something outside.

You didn't?

So, the result I provided is for when I ran the PoC outside of the sandbox.

There's some misunderstanding here. Yes, I did test it outside of Sandboxie, but not to verify if Sandboxie did something to the outside system. Hope this clears it up.

But anyway, other than that, I'm not sure I follow 100% without testing myself... I'll have to get that VM image downloaded.

So I guess you did NOT try by temporarily removing the hotfix? (Since "those not having" could test...)

No, I didn't remove the hotfix, as the system running Windows 7 is a production system, actually.

And you say he's right that it breaks the Sandboxie fix, yet you said previously that Sandboxie's errors are gone, even though you have the fix installed. That would suggest that it IS working still, just that perhaps the ONLY thing that needs it is either the kernel driver/SbieSvc SYSTEM process, which CAN still use SANDBOX_INERT.

Well, it's working for SandboxieRpcSs.exe, which runs as SYSTEM. Maybe the use of the flag SANDBOX_INERT made things work as they should with version 4. I'm not a developer per se, so just throwing it out loud. But, it's what makes most sense to me.

So, it makes sense that SandboxieRpcSs.exe, and other Sandboxie processes that run as SYSTEM ???, have no issues now.

Since if I understood right, you ARE still seeing something blocked as it should be in the sandbox? Of course, you have the fix installed, right, but just verifying. If so, yet Sandboxie is still working without errors in other parts that you had before, it would be nice if tzuk could ONLY use SANDBOX_INERT in the places where it's actually still having an effect, presumably (SYSTEM level), instead of on "all processes in the sandbox."

Yes, AppLocker is still blocking things in the sandboxes. Short version: Calling program B from program A will fail. AppLocker rule must be created.

I agree that it would be nice for SANDBOX_INERT to only work for processes related to Sandboxie running as SYSTEM.

[DR_LaRRY_PEpPeR]

There's some misunderstanding here. Yes, I did test it outside of Sandboxie, but not to verify if Sandboxie did something to the outside system. Hope this clears it up.

Ooops! I totally misread that!! Sorry, got it now.

Well, it's working for SandboxieRpcSs.exe, which runs as SYSTEM. Maybe the use of the flag SANDBOX_INERT made things work as they should with version 4. I'm not a developer per se, so just throwing it out loud. But, it's what makes most sense to me.

So, it makes sense that SandboxieRpcSs.exe, and other Sandboxie processes that run as SYSTEM ???, have no issues now.

RpcSs shouldn't be running as SYSTEM... I'm not seeing that -- it should be in its sandbox. However, it is now started by SbieSvc (since .05 I think), which is SYSTEM of course, so I think that's where the SANDBOX_INERT would still work (with hotfix), when SbieSvs is launching RpcSs.

[fanish]

RpcSs shouldn't be running as SYSTEM... I'm not seeing that -- it should be in its sandbox. However, it is now started by SbieSvc (since .05 I think), which is SYSTEM of course, so I think that's where the SANDBOX_INERT would still work (with hotfix), when SbieSvs is launching RpcSs.

You're right! I mistakenly believed it was running as SYSTEM, because it's a spawned process, and I just assumed it inherited the same rights, for some reason. It runs as UNTRUSTED. I don't know how I missed that, as I have Process Explorer configured to show the Integrity Levels column. But, because SbieSvc.exe runs as SYSTEM, then AppLocker will ignore SandboxieRpcSs.exe.

[Sadeghi85]

v4.0.1.07 works correctly. Thank you.