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"):
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:
Reproduction:
Preliminary steps:
Log in to the guest OS as a member of the local "Administrators" group.
Create a new user, which will be a member of only in the local "users"
group.
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.
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).
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.
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.
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.
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.
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: [email protected]
Past security advisories:
http://www.microsoft.com/technet/security/bulletin/MS02-003.mspx
http://support.microsoft.com/kb/315085/en-us
http://online.securityfocus.com/bid/4053
http://support.microsoft.com/?kbid=329350
http://online.securityfocus.com/bid/5972
http://www.securityfocus.com/archive/1/301624
http://online.securityfocus.com/bid/6280
http://online.securityfocus.com/archive/1/309442
http://online.securityfocus.com/bid/6736
http://www.securityfocus.com/archive/1/314361
http://www.securityfocus.com/bid/7046
http://www.securityfocus.com/archive/1/393800
http://www.securityfocus.com/archive/1/archive/1/434704/100/0/threaded
http://www.securityfocus.com/archive/1/archive/1/446220/100/0/
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)
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/