VxKex - Windows7 extended kernel - compatibility

[ask2018]

Describe what you noticed and did

Windows 7 extended kernel VxKex is not compatible with Sandboxie. I've already opened issue on VxKex github page here and the VxKex dev said that Sandboxie is rather invasive inside the target applications, and he is not interested in making any major changes to get it to work. So I'd like to ask, if there is something you can/want to do from Sandboxie side to fix this issue and make VxKex and Sandboxie compatible.

If I try to run any VxKex enabled application inside Sandboxie, I'm just getting crash you can see on this screenshot.

How often did you encounter it so far?

No response

Expected behavior

Sandboxie should work as normal on VxKex enabled applications.

Affected program

VxKex

Download link

https://github.com/vxiiduu/VxKex/releases

Where is the program located?

The program is installed only outside the sandbox.

Did the program or any related process close unexpectedly?

No, not at all.

Crash dump

No response

What version of Sandboxie are you running now?

Sandboxie Classic x64 v5.68.3

Is it a new installation of Sandboxie?

I have been using the same version for some time.

Is it a regression from previous versions?

No response

In which sandbox type you have this problem?

Not relevant to my request.

Can you reproduce this problem on a new empty sandbox?

Not relevant to my request.

What is your Windows edition and version?

Windows 7 x64 SP1 Enterprise ESU included

In which Windows account you have this problem?

Not relevant to my request.

Please mention any installed security software

Eset Endpoint AV, Agnitum Outpost FW

Did you previously enable some security policy settings outside Sandboxie?

No response

Trace log

No response

Sandboxie.ini configuration

No response

[DavidXanatos]

Hmm... that's a not so useful reply indeed... Of cause Sandboxie is invasive its probably the most invasive tool out there, full virtualization of all windows resources requires a lot of modifications to a programs normal behavior.

Sandboxie injects a piece of shell code named LowLevel.dll, its not loaded as a dll its position independent code injected directly by SbieSvc, as described here: https://sandboxie-plus.com/sandboxie/codeinjection/ (warning in later builds I have changed this a lot without updating the docs) This code sets up a few things, including a hook later in the code to load SbieDll.dll by calling LdrLoadDll Message SBIE2181 indicates that this failed, or the subsequent call to LdrGetProcedureAddress. I should info to that message which stage failed. You can check using a tool like TaskExplorer or SystemInformer to inspect your half failed process in this state to see if SbieDll.dll is listed in the loaded modules list.

Anyhow from the description of how VxKex is working

Q: How does VxKex work?

A: VxKex works by loading a DLL into each program where VxKex is enabled. This is accomplished through using the IFEO (Image File Execution Options) registry key.

Specifically, the "VerifierDlls" value is set to point to a VxKex DLL. This DLL then loads into the process.

And that info: https://skanthak.hier-im-netz.de/verifier.html about Application Verifier Provider which seams to be the mechanism for "VerifierDlls"

I would say that the VxKex DLL is loaded after the execution of the LowLevel.dll but before the hook to trigger the load of SbieDll.dll is invoked, based on the comments in VxKex DLL dllmain.c it seams that Application Verifier is not really used, only exploited as a vehicle to load the VxKex DLL what makes me think that a first thing to try would be to try to load the VxKex DLL using sandboxies own mechanism

InjectDll64=[path to 64 bit]\VxKex.dll
InjectDll=[path to 32 bit]\VxKex.dll

If the fault is caused by the Application Verifier mechanism then that would solve this issue, although VxKex DLL would need to be modified to do its thing on DLL_PROCESS_ATTACH instead of DLL_PROCESS_VERIFIER.

If the issue is caused by how VxKex DLL works and hooks things fixing that would be more difficult, and here IMHO the right way to do it would be to make VxKex DLL aware of SbieDll.dll and then use the hooking mechanisms provided by SbieDll.dll to do its thing.

So booth potential fixes require a change to VxKex DLL hence IMHO it would be reasonable to expect its developer to implement these, I don't think its ideal if I would have to maintain a SbieDll.dll aware fork of VxKex.

So the plan would be:

1. @ask2018 please test if sbiedll.dll was loaded or not on your system.
2. @vxiiduu should test if the simple fix is sufficient, it really might be and its a very simple fix.
3. If the simple fix does not work I can help with the SbieDll.dll aware approach.

[ask2018]

@DavidXanatos thank you for detailed answer. I've tried to load Infekt into the x64dbg. First try with VxKex only, second try with VxKex+Sandboxie and display loaded modules. Looks like SbieDll.dll is loaded. See the screenshots below.

[DavidXanatos]

It is loaded its the 5th module listed, so LdrGetProcedureAddress must be failing which is strange. Also notice that at this point no VxKex code has been loaded, so microsofts own verifier.dll must be breaking sandboxie operation.

This makes me think that if VxKex would be loaded not using the App Verifier mechanism it has a good chance of working.

[ask2018]

Yeah it is loaded, the "not" there was a typo. I edited the previous post, but you was too fast to reply :)

[ghost]

There is no mechanism other than VerifierDlls that I'm aware of which allows loading a DLL into a process before kernel32.dll and kernelbase.dll are loaded. I did extensive research on this topic. Using a kernel mode driver, or background service to load DLLs is not an option for me due to the design goals of VxKex (100% system stability and no extra background stuff running).

If we want to fix the problem the solution is to be creating a shim DLL, loaded by Sandboxie, which itself loads KexDll at some point just before kernel32.dll is loaded and then "pretends" to be the verifier subsystem, calling KexDll's entry point with DLL_PROCESS_VERIFIER and then hope that it magically works. I have a few doubts, since VxKex hooks a handful of NTAPIs and does a bunch of direct syscalls as well. Some of these hooks can be substituted with other methods, but some cannot. Personally I am not very interested in this topic right now, because I have a number of chrome and firefox related user experience problems to fix, and then tackling support for games. It would be an interesting exercise in the long term though.

As an aside, the Chromium sandbox, which I actually didn't have to change anything major to support, does not restrict the process token until the end of NTDLL's loader initialization. If Sandboxie works the same way there will be few problems.

[DavidXanatos]

I see, SbieDll.dll is currently using kernel32.dll so the lowlevel.dll would need to implement that functionality to load an other dll before loading sbiedll.dll for a simple fix attempt. Howe ever given how sandboxie operates it would be necessary to load sbiedll.dll first for this we would need to remove its dependencies on kernel32.dll and of cause direct syscalls are a big problem as well, sbie redirects almost all, except in a green box with NoSecurityIsolation=y so getting VxKex to work with a Compartment type box would still be feasible, if we resolve the loader issue.

[ask2018]

@vxiiduu I fully agree that fixing Chrome, Firefox and other user experience should be priority now. But after the major stuff is fixed, consider please also trying to fix this. In case Sandboxie will be still supported on Win7, I guess it will make the system usable and more secure in long term view for the users.

Thank you both guys for the replies, I appreciate it.

[ghost]

I see, SbieDll.dll is currently using kernel32.dll so the lowlevel.dll would need to implement that functionality to load an other dll before loading sbiedll.dll for a simple fix attempt. Howe ever given how sandboxie operates it would be necessary to load sbiedll.dll first for this we would need to remove its dependencies on kernel32.dll and of cause direct syscalls are a big problem as well, sbie redirects almost all, except in a green box with NoSecurityIsolation=y so getting VxKex to work with a Compartment type box would still be feasible, if we resolve the loader issue.

Does Sandboxie also "propagate" to child processes? I'm assuming it does, otherwise stuff could break out of the sandbox easily. That would be an even bigger problem, because VxKex also does that. The mechanism is by hooking NtCreateUserProcess and injecting a short piece of shellcode and using it to overwrite NtOpenKey, to trick the child process's loader into thinking VerifierDlls is enabled for the child process. This piece of shellcode obviously also does a direct syscall. (Code is in kexdll\propagte.c if curious). This functionality can be disabled though, so not really a big deal if the target application(s) do not require win8+ APIs.

[DavidXanatos]

In Sandboxie the driver are in charge of injecting sbiedll.dll into child processes, so the mechanism here is quite different.