Unfortunately the process is created as the desktop user which results in the elevated process sharing resources such as COM registrations with the normal user who can modify the registry to force an arbitrary DLL to be loaded into the VMX process. This prevents a non-administrator user opening the process and abusing its elevated access. To mitigate this the VMX process is created with an elevated integrity level by the authentication daemon (vmware-authd.exe) which runs at SYSTEM. As is common with desktop virtualization platforms the VM host usually has privileged access into the OS such as mapping physical memory which represents a security risk. Summary: COM classes used by the VMX process on a Windows host can be hijacked leading to elevation of privilege.ĭescription: The VMX process (vmware-vmx.exe) process configures and hosts an instance of VM. Platform: VMware Workstation Windows v14.1.5 (on Windows 10). However, I'd like to understand what's wrong and fix it.VMware: Host VMX Process COM Class Hijack EoP Since I can use NAT as a work-around, this isn't urgent. Happy to provide logfiles or other info to help debug the issue. Variations of this question seem to crop up frequently, but none of the questions I've read here on Superuser seem to directly address, or offer a fix for, this problem. Alas, I don't know which Mint upgrade, or VMWare Player upgrade broke the functionality, or when.
I've updated VMWare Tools in the guest OS, with no effect. Switch back to NAT, and everything reconnects and works fine.
Recently, I had need to switch to Bridged, and the guest Linux OS failed to connect. In the past (earlier versions of Linux Mint, and earlier versions of VMWare Player), I could switch networking between NAT and Bridged, and both would work as expected. Host hardware: ASUS Laptop with broadcomm wifi chipset.
0 kommentar(er)
