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@yahoo.com 

 
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)