Suggested severity level: Medium. Type of Risk: Denial of Service, Privilege Elevation, Un-authorize Access. Affected Software: VMware Workstation, version 5.5.3 build 34685 (including installation of "VMware Tools" of the same version, in the guest OS). (Older versions and other products by the vendor using the same components may be affected as well, but they weren't tested due to lack of resources. I advise administrators who use the corporate products of VMware to test this issues if they use this products in a production environment) Host and Guest OS: Windows XP Pro with SP2 and all the latest operational and security patches from the "windows update" site, up to 10-Feb-2007. (Older versions and other guest operating systems (especially ones by Microsoft) may be affected as well, but they weren't tested). Local / Remote activated: Local. Summary: If the "Toolbox" component of "VMware Tools" is installed on the guest OS, it is usually installed under the path "c:\program files\vmware\vmware tools\". When installed, the folder and its files inherit the security permissions from their father folder which itself inherits the permissions from the "c:\program files\" folder. Thus the permissions are as follows: Creator Owner, System, Administrators = Full Control. Power Users = Modify. Users = Read & Execute. The "VMware tools" installation also creates a service named "VMware tools service" which handles the communication and commands between the guest OS and the host OS. This service is running using the "System" privileged account. The above mentioned directory holds files, that when executed by a local user with a highest local group membership of "users", at the guest OS, can perform the following actions, which are prohibited by default to members of the local "users" group (and allowed only to more privileged groups like "Power Users" and "Administrators"): 1. Change the system time (limited to setting the guest OS time to be in-sync or out-of-sync with the time of the host OS - thus changing the time accordingly, but not setting a specific date and/or time) 2. Disable or enable the VM "hardware" devices (limited to Network Interface Card, Optical drive, Floppy drive and the Audio card) 3. Stop a service (limited to the "VMware tools service" service) This operations are performed at the VMware level, one level "outside" the OS, so the OS itself maintains its security rights model working normally and enforcing its rules - but since the "VMware Tools" component is enabling direct access to the machine's "hardware", the effective result is similar to privileges elevation (at a partial scope, as mentioned above). I guess the main reason for this happening is because VMware Workstation does not enforce any authentication and authorization mechanism, within the guest OS, when performing this actions. Thus it looks like any user in the guest OS, probably at any security group membership level, can perform this actions if he has the access to read and execute the needed files. Further tests I have performed shows that even if the permissions will be hardened at the above path or even if the Toolbox component will be uninstalled completely (also removing the "VMware tools service" service) - if a user will be able to load the needed files to the guest OS, and execute them from any path - the results will be the same (for the "hardware" related actions) since the vulnerability is built-in from the way this files communicate with VM "hardware". Possible Abuses: 1. Changing the system time of the guest OS, to be in-sync or out-of-sync with the host OS - thus causing a global system change, effecting events scheduling, files and folders time stamps, event logs records time stamps, etc. . 2. Shutting down hardware components, which the most important of them is the network card. 3. Activating disabled hardware components (that may have been disabled to assure isolation between the guest OS and the host OS) can grant the abilities to: 3.1. Play sounds and voices from the guest OS to the host OS physical environment. 3.2. Allow access to read and write data stored on removable storage devices (CD/DVD and/or floppy). 3.3. Connect an isolated guest OS to the host OS and its network(s) and maybe to the internet, by enabling the network card. 4. Stopping the service that connects and controls the operations between the guest and the host operating systems (the "VMware tools service" service). Reproduction: Preliminary steps: 1. Log in to the guest OS as a member of the local "Administrators" group. 2. Create a new user, which will be a member of only in the local "users" group. 3. Perform an install of "VMware Tools" to the guest OS (only the "Toolbox" component is needed. Other component are irrelevant and it doesn't matter if they are installed or not). This is done from the VMware workstation interface, by clicking the "Install VMware tools" command from the "VM" menu. Restart the guest OS if asked to. 4. Log off and then log into the guest OS as the limited user. Perform all the following reproduction sections with this user (unless instructed differently). 1. Changing the system time 1.1. Try to change the system time from within the guest OS by double clicking the clock at the "task bar" (or by running timedate.cpl) and you will receive an error message that this account does not have the needed privilege to perform this operation. 1.2. Activate the VMware tools control panel in one of the following ways: 1.2.1. Double click the VMware icon, if one is presented at the task bar, beside the clock. 1.2.2. Open the OS "control panel" and double click the VMware icon. 1.2.3. Run the file "c:\program files\vmware\vmware tools\VMControlPanel.cpl". 1.3. Un-check the checkbox "Time synchronization between the virtual machine and the host operating system" in the "options" tab, then click "apply". 1.4. Change the system time of the host OS to be one hour in advance of the system time of the guest OS (This steps are performed at this stage since "VMware Tools" is installed with the time sync component set as enabled). 1.5. Return to the VMware Tools control panel at the guest OS and enable the checkbox "Time synchronization between the virtual machine and the host operating system". 1.6. Click "Apply". 1.7. Notice that the time of the guest OS is now changing to be the same as the one of the host OS. 1.7.1. Strangely, this "on-the-fly" change works only if the host OS time is in advance of the guest OS. I guess this is a bug, since it also happens when performing this action as an administrator. 1.7.2. A change of the time in the opposite direction, to be in-sync with an earlier host OS time will go into effect only if the checkbox is selected and the guest OS is restarted. 1.7.3. My tests shows that this issue is possible only if the host OS and the guest OS are in the same time zone. This can also be done in a reverse mode - from checking to un-checking this checkbox, and thus, if the host OS time will change (like in daylight saving) - the guest OS time will not be changed. 2. Stopping the "VMware tools service" service 2.1. Run the command: cmd.exe (run all following commands within cmd) 2.2. run the command: net start 2.3. Verify the "VMware tools service" service is on the list of active services. 2.4. Run the command: net stop "VMware tools service" 2.5. Notice an error is presented stating that it is not possible to stop the service because "access is denied". 2.6. Run the command: net start 2.7. Verify the "VMware tools service" service is on the list of active services. 2.8. Run the command: "C:\Program Files\VMware\VMware Tools\vmwareservice.exe" -kill (type the command (upper/lower case is irrelevant), since (strangely) copying the command from the host OS and pasting it to the command prompt at the guest OS did not work) (notice an error message will appear. you can ignore it) 2.9. Run the command: net start 2.10. Verify that: 2.10.1. The "VMware tools service" service is NOT on the list of active services. 2.10.2. A "no entrance" sign is showing now on the icon of the VMware tools beside the task bar (if the icon was set to be presented). Stopping this service will only stop the option of synchronizing the time between the guest OS and the host OS, but the ability to enable and disable devices will still be operational. 3. Disabling or enabling hardware devices 3.1. Try to disable any hardware component known to the guest OS by running devmgmt.msc and you will receive an error message that you do not have the needed privileges to perform this operation, and when "Device Manager" will be opened you will have no option of disabling or enabling any hardware shown in this applet. 3.2. Open the VMware tools control panel. 3.3. Click on the "Devices" tab and un-check any one of the enabled checkboxes (the number and type of components may change based on the configuration of the specific VM): 3.3.1. IDE 1:0 (the CD/DVD optical drive) 3.3.2. Floppy 1 3.3.3. NIC 1 3.3.4. Audio 3.4. Click "Apply". 3.4.1. Notice how the relevant hardware icons on the lower right corner of the VMware Workstation interface are changing to include "X" mark, indicating they are disabled. Also notice hardware alerts in the guest OS (especially concerning the NIC), and try to perform actions with the now-disabled devices to confirm that this devices really can't be used in the guest OS (even though the guest OS "device manager" shows they are enabled). 3.5. Now enable any disabled devices using the VMware Tools control panel and watch how the guest OS is re-connecting this devices. Try to work with this devices and make sure you can perform input-output operations with them. A user can enable in this way devices that were disabled by an administrator (or any other user) of the guest OS or disabled by the VMware Workstation operator, from the host OS (from the time before the VM was started and from any time while the VM is running (on-the-fly disabling)). 3.6. Minimal requirements for this "hardware" actions to work: 3.6.1. In the guest OS, Log off and then log in as an administrator. 3.6.2. Copy the following two files to any directory were they can be read and executed by any regular user, like c:\temp (verify the permissions): 3.6.2.1. "c:\program files\vmware\vmware tools\VMControlPanel.cpl" 3.6.2.2. "c:\windows\system32\msvcr71.dll" 3.6.3. Using the "add/remove programs" applet from the guest OS control panel (appwiz.cpl) - Uninstall the "Toolbox" component of "VMware Tools" (you can leave other components of the "VMware Tools" installed or you can remove them all - they are irrelevant). The above mentioned two files will be deleted from their original locations. Restart the guest OS if asked to. 3.6.4. Log off and log in as the regular user. 3.6.5. Run "c:\temp\VMControlPanel.cpl" and make sure you are able to repeat the above mentioned enable or disable actions with the same success. Thus, if an attacker can load this two files to a VM, one that doesn't even have the "Toolbox" component installed or even the whole "VMware Tools" installed - he can still perform this malicious "hardware" related actions. Exploit Code: No need. Attack automation may be possible using the VMware API (although I didn't try it). Possible commands may use keywords like: power (for trying to power off the guest OS), connect , disconnect http://www.vmware.com/support/developer/scripting-API/doc/Scripting_API. pdf http://www.vmware.com/pdf/Scripting_API_23.pdf http://pubs.vmware.com/foundry1/wwhelp/wwhimpl/js/html/wwhelp.htm http://www.vmware.com/pdf/Prog_API_Prog_Guide.pdf http://www.vmware.com/pdf/Prog_API_Ref_Guide.pdf http://www.vmware.com/support/developer/prog-api/ (some scripts example files on this page) Direct resolution: Not any that I am aware of at the time of writing this advisory. Workarounds: Warning! - As mentioned above, there is a need for only two files (easily available publicly) to be loaded and run in guest OS to perform "hardware" related malicious actions, so the following workarounds are very limited and will only work (especially the second one) if there is an absolute way to assure a local user can't inject this files to the guest OS and execute them. 1. Hardening the permissions to folders, files and registry keys of "VMware Tools": Be careful and notice that all of following steps will revoke the "users" group access from the whole of the VMware folders, files and registry keys, effecting also other guest OS components installed by VMware, like drivers and shared folders, not just the "Toolbox" component. 1.1. Log in to the guest OS as an administrator. 1.2. Run the command: cacls "c:\program files\VMware" /T /E /R users 1.3. This will remove the "users" object from the "c:\program files\VMware" path and below, for all folders and files, thus preventing access to members of the local "users" group. 1.4. Change the permissions for following registry keys: 1.4.1. Break the permissions inheritance of the following registry keys and remove the "users" object from all of them, including sub-keys as well: 1.4.1.1. HKLM\SYSTEM\CurrentControlSet\Services\vmmouse 1.4.1.2. HKLM\SYSTEM\CurrentControlSet\Services\vmscsi 1.4.1.3. HKLM\SYSTEM\CurrentControlSet\Services\VMTools 1.4.1.4. HKLM\SYSTEM\CurrentControlSet\Services\vmx_svga 1.4.1.5. HKLM\SYSTEM\CurrentControlSet\Services\vmxnet 1.5. This workaround is less desirable than uninstalling the "Toolbox" component (see the next workaround), which remove the vulnerable files completely from the guest OS. 1.6. If a user will be able to load the minimum files needed to manipulate the "hardware", then the only benefit from this workaround will be that the user will be unable to stop the "VMware tools service" service. 2. Uninstall the "Toolbox" component of the "VMware Tools": 2.1. Log into the guest OS as an administrator. 2.2. Activate the "add/remove programs" applet from the OS control panel (appwiz.cpl). 2.2.1. Select "VMware Tools" from the list of installed applications and click "change". 2.2.2. Follow the wizard and choose the "modify" setup mode. 2.2.3. In the components section - choose to remove only the "Toolbox" component and continue with the setup. Restart the guest OS if asked to. 2.3. This step will remove the Toolbox files from their original locations, any related registry values and the "VMware tools service" service. The anti-manipulation "Lockout" feature (VM Workstation interface -> Edit menu -> Preferences command -> Lockout tab) has been tested and is affecting only the access to the interface of VMware workstation, thus only from "outside" of the running VM, from the host OS - so it can't help with the issues mention in this advisory. Vendor Notification: The vendor was notified at the end of September 2006, but it could not commit to any planned date for a fix regarding any of this issues. Credit: Eitan Caspi Israel Email: eitancaspi (at) yahoo (dot) com [email concealed] Past security advisories: 1. http://www.microsoft.com/technet/security/bulletin/MS02-003.mspx http://support.microsoft.com/kb/315085/en-us http://online.securityfocus.com/bid/4053 2. http://support.microsoft.com/?kbid=329350 http://online.securityfocus.com/bid/5972 3. http://www.securityfocus.com/archive/1/301624 http://online.securityfocus.com/bid/6280 4. http://online.securityfocus.com/archive/1/309442 http://online.securityfocus.com/bid/6736 5. http://www.securityfocus.com/archive/1/314361 http://www.securityfocus.com/bid/7046 6. http://www.securityfocus.com/archive/1/393800 7. http://www.securityfocus.com/archive/1/archive/1/434704/100/0/threaded 8. http://www.securityfocus.com/archive/1/archive/1/446220/100/0/ 9. http://www.securityfocus.com/archive/1/459140/30/90/threaded http://www.securityfocus.com/bid/22413 Articles: You can find several articles I have written (translated to English) at http://www.themarker.com/eng/archive/one.jhtml (filter: Author = Eitan Caspi (second names set), From year = 2000 , Until year = 2002) Eitan Caspi Israel Current Blog (Hebrew): http://blog.tapuz.co.il/eitancaspi Past Blog (Hebrew): http://www.notes.co.il/eitan Dead Blog (English): http://eitancaspi.blogspot.com "Technology is like sex. No Hands On - No Fun." (Eitan Caspi)