ISSUE: Some MSI installers fail to install in Sandboxie.

ISSUE: Some MSI installers fail to install in Sandboxie.

Unable to execute some program installers (MSI) in the sandbox beginning with Windows 10 v1809 + Sbie 5.27.1
Forum thread:
https://community.sophos.com/products/sandboxie/f/forum/115139/sb-v5-31-4-the-windows-installer-service-could-not-be-accessed-when-trying-to-install-programs

Repro steps

Attempt to execute Mumble installer in Sbie

https://www.mumble.info/downloads/

The mumble installer will popup the error message:

"The Windows Installer Service Could Not Be Accessed".

 

Description

In host Win 10, when you execute an MSI file, Windows starts msiexec.exe, which creates an MSIServer COM object {000c101c-0000-0000-c000-000000000046} that resides in services.exe. Services.exe then starts a new child msiexec.exe process that performs the actual installation.

There is COM communication between all these processes. Sbie blocks this communication. After opening the CLSID above, we are able to instantiate the COM object in services.exe, but then we get fatal errors. SbieSvc.exe in the host fails when it tries to invoke a method in SbieSvc.exe running in the guest.

combase!ClientResolveOXID returns 776, OR_INVALID_OXID (0x80070776)

SbieSvc.exe host stack

RPCRT4!NdrpClientUnMarshal+0x2dd
RPCRT4!NdrpClientCall2+0x41c
RPCRT4!NdrClientCall2+0x1f
combase!ClientResolveOXID+0x4f [onecore\com\combase\idl\internal\daytona\objfre\amd64\lclor_c.c @ 277]
combase!CRpcResolver::ClientResolveMachineLocalOXID+0x9f [onecore\com\combase\dcomrem\resolver.cxx @ 1277]
combase!COXIDTable::ClientResolveMachineLocalOXID+0x21d [onecore\com\combase\dcomrem\ipidtbl.cxx @ 3166]
combase!ReadObjRef+0x177 [onecore\com\combase\dcomrem\marshal.cxx @ 9565]
combase!CoUnmarshalInterface+0x7b [onecore\com\combase\dcomrem\coapi.cxx @ 1938]
combase!NdrExtInterfacePointerUnmarshall+0x1b3 [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1168]
RPCRT4!NdrPointerUnmarshall+0x384
RPCRT4!NdrpServerUnMarshal+0x1b4
RPCRT4!NdrStubCall2+0x1fd
RPCRT4!NdrStubCall3+0xe3
combase!CStdStubBuffer_Invoke+0x5f [onecore\com\combase\ndr\ndrole\stub.cxx @ 1524]
RPCRT4!CStdStubBuffer_Invoke+0x3b
SbieSvc!ComServer::InvokeMethodSlave+0x10d [c:\src\sandbox\projects\core\svc\comserver.cpp @ 2061]
SbieSvc!ComServer::RunSlave+0x4b3 [c:\src\sandbox\projects\core\svc\comserver.cpp @ 1484]
SbieSvc!WinMain+0xb8 [c:\src\sandbox\projects\core\svc\main.cpp @ 118]
SbieSvc!invoke_main+0x21 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 94]
SbieSvc!__scrt_common_main_seh+0x117 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 253]
KERNEL32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

 

SbieSvc.exe guest stack

KERNELBASE!RaiseException+0x69
RPCRT4!RpcpRaiseException+0x34
RPCRT4!RpcRaiseException+0x14
combase!NdrExtInterfacePointerUnmarshall+0xc3cfa [onecore\com\combase\ndr\ndrole\oleaux.cxx @ 1172]
RPCRT4!NdrPointerUnmarshall+0x384
RPCRT4!NdrpServerUnMarshal+0x1b4
RPCRT4!NdrStubCall2+0x1fd
RPCRT4!NdrStubCall3+0xe3
combase!CStdStubBuffer_Invoke+0x5f [onecore\com\combase\ndr\ndrole\stub.cxx @ 1524]
RPCRT4!CStdStubBuffer_Invoke+0x3b
SbieSvc!ComServer::InvokeMethodSlave+0x10d [c:\src\sandbox\projects\core\svc\comserver.cpp @ 2061]
SbieSvc!ComServer::RunSlave+0x4b3 [c:\src\sandbox\projects\core\svc\comserver.cpp @ 1484]
SbieSvc!WinMain+0xb8 [c:\src\sandbox\projects\core\svc\main.cpp @ 118]
SbieSvc!invoke_main+0x21 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 94]
SbieSvc!__scrt_common_main_seh+0x117 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 253]
KERNEL32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

Unfortunately, this is not just a matter of opening IPC ports. I believe the host process SbieSvc.exe is attempting to use EPMapper to find a DCOM object in the sandbox that does not exist. Hence the error OR_INVALID_OXID. So, somehow we may need to ensure that all required DCOM objects exist in the sandbox, or intercept these accesses to EPMapper. Additional research is required which will include some reverse engineering of Windows RPC, msiexec.exe, combase.dll, EPMapper, etc.

Note: In Windows 10, services.exe is a protected process. This means you cannot attach a debugger to it and the stacks will not be decipherable in ProcMon. You must run Windows under the kernel debugger and manually change the “Protection” field of the EPROCESS structure. Search for articles on the web for more details.

Parents Reply
  • The things are still developing so not sure whats the best coarse about naming and versioning. I think for a release that will closely follow the paradigms of the original sandboxie its best to keep the version numbers increasing. For a release that changes a lot and restarts some things from scratch a new version number is best. For example I'm looking into a replacement for SbieCtrl that is Qt based and has a more advanced UI.

    The most likely way forward will be two release channel Sandboxie 5.xx and Sandboxie Plus 1.xx ideally booth should use the same driver and possibly service, the more components can be shared the better.

Children