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.
