VMware Multiple Products - Privilege Escalation

CVE-2015-3650

Introduction
This article summarises the findings and the impact of a vulnerability that we recently discovered in three major VMware Windows products. The affected products are ‘VMware Workstation’, ‘Horizon Client’ (with Local Mode Option), and ‘Player’.
Successful exploitation of this vulnerability allows a local attacker to execute code in the context of other logged-on user accounts in the same host.
The resulting impact can be either horizontal or vertical privilege escalation depending on the account from which the attack is launched and the targeted user account that uses vulnerable VMware software for Windows.
Securable Objects
As their name dictates, these are Windows objects that live in the kernel address space and have security descriptors so that the operating system can control who can access what and at what level.
These descriptors are structures that contain security information associated with those objects. Normally, a security descriptor should have a valid pointer to discretionary access control list (DACL) which can be comprised by one or more access control entries (ACEs) as shown in Figure 1.

Figure 1. Discretionary Access Control List

An ACE describes which groups and individual users can or cannot access a securable object, and the type of access such as Read, Write, Execute, Read|Write etc…
For most of these securable objects, we can set our own security descriptors when we create them in order to customise access to them.
As shown in Figure 1, we want to allow full access to the users that belong to the ‘A’ group (Write + Read|Execute for Everyone group), and Read|Execute to everyone else, but we want to exclude Andrew from being able to access that object.
Unless for some reason we need to grant or deny access to a specific user or group of users, it is generally not necessary to specify our own security descriptors for securable objects that we create. These objects will only allow access by default to users or groups that have the necessary privileges to do so. Indeed, the system will provide a default DACL for a securable object when we don’t specify a security descriptor for it.
If for example we create a process that runs in the security context of an account that belongs in the Administrators group, then another process that runs in the context of a standard or guest user account should not be able to access it, or at least it should have very limited access to that process.
Indeed, customising access to securable objects that we create can be risky and lead to critical vulnerabilities. For this reason developers must be very careful when they do so.
As already mentioned, security descriptors should have a valid pointer to a DACL that contains one or more ACEs. However, a DACL can also be empty which means that access to this object is denied to everyone. A design error of this type would probably cause some sort of denial of service to any process that would need access to that particular object.
On the other hand, a more severe design error that can be created in the attempt of customising access to a securable object is to provide a NULL DACL pointer to the security descriptor of that object. This would allow any user to fully access that object, even if that object has been created in the security context of a higher privileged user, in which case the system should normally deny full access (Read|Write|Execute) to lower privileged users.
The Ugly DACLing
Unfortunately, not every fairy tale has a happy ending, especially when it is pretty much associated with a 0-day vulnerability in a real life scenario. Yes, NULL DACLs can be really ugly when it comes to security, and they don’t get any prettier.
Recently, VMware patched a critical security issue that we reported to them. This issue was mainly affecting all VMware Workstation, Horizon Client (with Local Mode Option), and Player versions since the virtual printer device was introduced.
This device allows a virtual machine with VMware tools installed to access a printer configured in the host. Adding this device to the virtual machine device settings was originally optional. However, in the more recent versions of these products the virtual printer device is added by default whenever a user creates a new virtual machine.
The discovered vulnerability is based on a NULL DACL assignment to the security descriptor of the vprintproxy.exe process which handles the virtual printer device in the host.
Every time a user launches a virtual machine, an associated vmware-vmx.exe process will run in the security context of the user that launched the virtual machine.
However, if the virtual machine has the virtual printer device enabled, or if the user connects that device while the virtual machine is active, then vmware-vmx.exe process will spawn vprintproxy.exe process. In the steps taken to configure a custom security descriptor for this child process, the privilege escalation vulnerability is introduced.

Figure 2. Assigning the NULL DACL

As shown in the above figure, vmware-vmx.exe makes a call to the SetSecurityDescriptorDacl function, but fails to provide a valid pointer (R8 Register) to an ACL structure that specifies the DACL for the created security descriptor.
Once the new security descriptor is created, it will be used in a subsequent call to CreateProcess function (Figure 3) to launch vprintproxy.exe which will create a process object with a NULL DACL assigned to it.

Figure 3. Launching vprintproxy.exe with a NULL DACL

The Impact
The newly created vprintproxy.exe process runs in the security context of its parent process, which in turn runs in the security context of the user that launched the virtual machine instance.
However, because the object associated with vprintproxy.exe process has a NULL DACL in its security descriptor, it allows any user to fully access it and execute code in the context of this process by injecting a remote thread to it.
In a few words, if a virtual machine has been launched from an Administrator account, then a guest or a standard user that is currently logged-on in the same host can execute code in the security context of the Administrator account, thus obtaining full access to files and other resources that normally the system wouldn’t grant access to.
The Vendor Fix
VMware has provided a fix for the two most recent major versions of VMware Workstation, which are v10.x (v10.0.7) and v11.x (v11.1.1), as well as for the associated VMware Horizon Client v5.4.2, and Player v7.x (v7.1.1) and v6.x (v6.0.7) respectively.
Earlier versions of these products will not be patched, which means that using these products in a Windows host where multiple users are logged on at the same time, might pose a critical security risk.
The following two figures demonstrate the results of the applied fix.

Figure 4. Assigning a valid pointer to an ACL structure

Figure 5. Launching vprintproxy.exe with a valid DACL

VMware has created the following security advisory: https://www.vmware.com/security/advisories/VMSA-2015-0005
A Workaround Fix
If for any reason terminating one of the aforementioned VMware products in order to apply the updates is not an immediate option, the account owner can choose to permanently disable the virtual printer device from all the virtual machines, and ensure that there are no vprintproxy.exe processes still active. However, this should only be a temporary solution since the Vendor’s supplied update can contain fixes for other security related issues as well.
Conclusion
Creating custom security descriptors might be quite risky, and most of the time this is really not necessary, since the system always applies a default DACL to protect securable objects from being fully accessed by a lower privileged user.
However, it is necessary to do so if we want to create more strict rules for protecting a securable object from specific users or groups.
In this case, I had initially patched, for testing, the vulnerability in vmware-vmx.exe by simply passing a NULL pointer to the SECURITY_DESCRIPTOR parameter of the CreateProcess function. This forced the system to assign a default DACL to the vprintproxy.exe process which didn’t allow any more lower-privileged users to access this process. Even though this was just a POC fix, it didn’t cause any issues while using the software.
The demo video below demonstrates how a local attacker elevates his privileges from a Guest to SYSTEM account by exploiting CVE-2015-3650 in VMware Workstation v11.1.0.

 
References

1. https://msdn.microsoft.com/en-us/library/windows/desktop/aa379557%28v=vs.85%29.aspx
2. https://msdn.microsoft.com/en-us/library/windows/desktop/aa379563%28v=vs.85%29.aspx
3. https://msdn.microsoft.com/en-us/library/windows/desktop/aa446597%28v=vs.85%29.aspx
4. https://msdn.microsoft.com/en-us/library/windows/desktop/aa379583%28v=vs.85%29.aspx
5. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

To contact the Nettitude editor, please email media@nettitude.com.