I have run across a design issue in VMware's scripting automation API that diminishes VM guest/host isolation in such a manner to facilitate privilege escalation, spreading of malware, and compromise of guest operating systems. VMware's scripting API allows a malicious script on the host machine to execute programs, open URLs, and perform other privileged operations on any guest operating system open at the console, without requiring any credentials on the guest operating system. Furthermore, the script can execute programs even if you lock the desktop of the guest OS. For example, if a non-admin user is logged in at the vm host, but logged in to guest operating systems as an administrator, the script running as a non-admin on the host can still execute admin-level scripts on the guests. I obviously did not discover this issue--the API developers provided it as a feature-I am simply pointing out the potential danger, that it was a poor design decision, and that there is a need to establish best practices for virtual machine guest and host isolation. Background Virtual machines have become a more integral part of the computing world and are playing an increasing role in IT infrastructures. It is not uncommon to use virtual machines for everything from testing to critical server roles. One benefit of using virtual machines is that it allows you to work with several operating systems on the same machine and provides effective isolation between each operating system. The VIX API provides an interface to manipulate virtual machines from the host machine. This API is available on any machine with VMware Server or Workstation installed. Certain commands-such as RunProgramInGuest -do require authentication to run commands on a VMware guest OS, you can instruct them to use the credentials of the user currently logged in at the console. If no user is currently logged in, the command can wait until the next user does log in. The risk here is that although the guest OS is a separate operating system environment, a script on the host machine can still execute programs in any guest machine without knowing any actual login credentials. This would allow malware to propagate to guest OS's without any additional credentials. Scenario Many IT professionals have begun to use virtual machines for critical infrastructure systems. In my own environment I use specialized virtual machines for development and administration. The snapshot features and easy backup capabilities of virtual machines make them convenient for dedicated administrative environments. Since I-as well as many administrators-normally stay logged in to my desktop as a non-admin user, it is convenient to have separate virtual machines for performing administrative functions. I have also done this to gain further isolation so that normal PC activities such as browsing the Internet and reading e-mail do not compromise administrative access to my network. The problem is that a malicious script running within the context of a regular user on my desktop can run administrator-level scripts on any guest I am currently logged in to. Using Ctrl+Alt+Del to lock the desktop of those machines does not prevent VIX from executing commands on the guest. Even if I log out of each guest machine the malware can just queue the command to run the next time I log in at the console of the guest OS. Remediation I contacted VMWare about this issue several months ago and they responded that his was "a very difficult design choice". Their response was that anyone who is able to connect to a guest via the VIX api would also have the capability of accessing the virtual disk files of the machine and compromise the guest that way as well. While that is true, it is also possible to use full disk encryption and other countermeasures that prevent access to a host resulting in compromise of the guests. Furthermore, being able to automate something is a big deal when it comes to spreading malware. Give me access to any system on a foreign network with user-level credentials and before too long I can acquire full admin access, but for a worm to be able to automate that in seconds is something completely different. But rather than try to argue with VMWare about the severity of the issue, I chose to simply make you all aware that the potential is there and you can decide for yourselves. Fortunately, there is an undocumented switch to turn this off. In the VMX config file, you can add the following: guest.commands.anonGuestCommandsRunAsConsoleUser=FALSE You can also set this on the host-wide configuration file, so it will override the config setting in every VM. So with that, I would like to establish a best practice for virtual machine guest/host isolation: A virtual server host should never provide any mechanism that, by default, allows guest-to-host or host-to-guest access without having to follow standard authentication procedures and protocols for the target operating system. This original post can be found here: http://xato.net/bl/2007/08/22/vmware-guest-isolation-vulnerability/ Mark Burnett http://xato.net
Attachment:
smime.p7s
Description: S/MIME cryptographic signature