- It's the applications, stupid
- Will a whitelist save personal computing?
- Thousands of Web sites under attack
- To solve the unsolvable problem
- Re-thinking the security of virtual machines
- Security Development Lifecycle trumps code complexity
- Is your Web site FIPS compliant?
- Computer security: Why have least privilege?
- Strategic security: Get a handle on authentication
- Control user installs of software
August 23, 2007 | Comments: (0)
VMware scripting automation API allows local exploitation
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
Posted by Roger Grimes on August 23, 2007 04:06 PM
RATE THIS ARTICLE:
-
- COMMENTS
Not exactly an insightful article. Any compromise of a host system allows compromise of a guest system. Great timing on the article though. Bet you get lots of hits from people looking for news on VMware's success.
Mark Burnett adds further clarification:
I hate writing such a long post here, but I think it's important that I clarify some points:
1. Of course this won't issue won't affect everyone, especially if you are using vmware mainly for hosting server roles and especially if you do not run the client utilities, but even if it affects 10% of the people out there, it is still an issue. Remember the MSBlaster worm? At it's peak it had only infected about 150,000 systems--a very small percentage of Windows
machines.
2. This issue is not about a user on the host compromising a virtual guest. It is about a *non-privileged* user on the host being logged in to guest machines as an administrator, and a worm--running in the context of that non-privileged user on the host--being able to access the admin-level context of the guest machines without knowing those administrator credentials. Also remember that since I am talking about a non-privileged user on the host, there will be limits on what this user could do to accomplish some of the other attacks mentioned.
3. It's not just the ability to access the guest OS's that is significant here, it's the *automated* access that is key. There are endless ways you could own a guest OS manually. But with the API just a few lines of code could enumerate all open guests and execute commands in each. This attack requires no interaction or trial-and-error in attacking the guest OS's, nor does it require any login credentials on any guest OS. This is all significant because it would be an easy way for an automated (and lightweight) worm to propagate. This isn't so much about guest OS compromise as it is about malware propagation.
4. This is also not so much about this specific issue at hand--we can easily block this--but also looking at the bigger picture of establishing best
practices for dealing with the guest/host relationship.
5. Arthur, it may not affect you but the way you use virtual machines is likely not representative of the population of vmware users.
6. The argument that a secured server won't be vulnerable is fine, but that's a pretty big assumption to make. There are few vulnerabilities ever found that couldn't be reasonably anticipated and prevented by following
long-established security best practices. But somehow people still keep getting hacked or infected. So yeah we could stop this stuff if everyone was secure but they aren't.
Finally, let me explain how I personally use virtual machines to put this all in context of why I think this is important. I use Windows Vista as my host machine, logged in as a non-admin user. I am typing this e-mail--also as a non-admin user--in a Windows XP virtual machine dedicated to instant messaging and e-mail. On another monitor I have a VM running Windows 2003 as a domain controller (btw, you need the client utilities on domain controllers to keep the clock correct) where I am logged in as an administrator, but the screen saver is password-protected and I lock the console anyway when I am finished using it. On that machine I have a number
of admin and networking tools installed. Finally, I have yet another Windows XP virtual machine running with a lot of my pen-testing tools. Many of these just don't work well unless you are an admin, so I am logged in as an admin. That machine is "paused" and I start it up when I need it. I probably have a dozen other specialized machines paused for different client projects I am
working on.
As a side note, I specialize in hardening Windows so all of these systems have been hardened with my own hardening script that is quite extreme. These are by no means weak targets. I also make sure the guest machines are fairly isolated by not allowing shared drives or drag/drop between machines.
Remember that so far there has been no security reason not to run the client utilities, and using a windows guest really sucks without having them
installed.
Since I do much of my web browsing on the Vista host machine, I thought this whole setup was a secure way to isolate everything. I keep my browsing,communications, client work, and administrative tasks on isolated machines.
However, if a worm were somehow able to run on my Vista host, it could likely compromise all the other guests OS's including those where I am
logged in as an admin, and it could do it in seconds with just a tiny payload of just a few lines of code. So running a script as a non-admin user could mean my whole network is owned in seconds.
It doesn't matter how secure all my guests are or that I use extremely secure passwords or that I am current on all my patches or I am running a
super-tight firewall on each guest. A single API call bypasses all of that. A script wouldn't even need to know the administrator's name, which isn't
administrator on all my systems, it just runs commands as whatever user has logged in to the console. Locking the guest OS screens or having a
password-protected screen saver doesn't help any either, the code still runs.
So you can see that there are many different ways that people user virtual machines. Not just as servers, but as workstations as well. And not just
linux, but Windows too. A prudent administrator has no reason to expect a guest machine to become vulnerable just by installing the guest utilities.
There has been no reason to think that being logged in as a non-admin user on the host could still result in a compromise of the admin credentials in the guest OS's.
But now there is.
Mark Burnett
http://xato.net
VMware's Official Response and Easy Fix:
*Summary*
VMware VIX API 1.1 supports an option that allows users with privileges on the host machine to execute programs on a guest operating system under the identity of a user currently logged into the guest. For example, if user A powers on a virtual machine (VM) and logs into the guest operating system, then a user B who has privilege on the host machine to connect to that VM can also write scripts that will anonymously run programs in the VM guest operating system as user A.
Note that the only users who can access the VM this way are either the same users who have powered on the VM or an administrator on the host.
*Affected products:*
This behavior is only present in Workstation 6.0 and VMware Player 2.0.
This issue does not affect any released version of VMware Server, VMware ESX Server, or VMware GSX Server.
*How to disable this behavior*
You can disable this behavior by adding an entry to the host configuration file. This will override any VM-specific configuration and globally disable the behavior for all virtual machines running on the host.
The host configuration is owned by the System/root account, so it is protected against non-root users who have virtual machines on the system.
This behavior can be disabled at the host level by adding the following line to the host configuration file:
guest.commands.anonGuestCommandsRunAsConsoleUser = "FALSE"
On Linux, the default pathname for this file is:
/usr/lib/vmware/settings
(Note that "settings" is the file name, not another directory name.)
On Windows (except Windows Vista), the default pathname for this file is:
C:\Documents and Settings\All Users\Application
Data\VMware\VMware Workstation\settings.ini
On Windows Vista, the default pathname for this file is:
C:\ProgramData\VMware\VMware Workstation\settings.ini
(Note that on Windows Vista, the "ProgramData" directory may be hidden by default.)
If you installed the product in a custom location, then the path name for the configuration file may be different.
Normally, the file will not exist. If the file does not exist, then first create a new blank text file named "settings" on Linux and "settings.ini" on Windows and then add the new settings line.
Alternatively, you can also add the following line to the VMX configuration file to disable the behavior on a per-VM basis:
guest.commands.anonGuestCommandsRunAsConsoleUser=FALSE
The only feature of VMware Workstation that relies on this behavior is the Integrated Virtual Debugger, i.e. the optional plugins for Eclipse IDE and Microsoft Visual Studio. Disabling this login mode as documented above will disable this feature.
In addition, VIX API client programs and scripts which depend on this login mode while calling VixVM_LoginInGuest will need to be modified to use a username and password to login to the guest.
*The rationale for this design decision*
We added this functionality to VMware Workstation in order to provide a seamless user experience using Integrated Virtual Debugger – a user will not be prompted to log-in each time a program is launched to run/debug inside a VM.
We determined that, although this automates interaction with the guest operating system, this is not a /bona fide/ escalation of privileges in the guest operation system because any user who can access the VM this way can already open the user interface and manually interact with the guest under the identity of the currently logged-in user.
In other words, if you are able to connect to a running VM, you need to be either the user who powered on the VM, or you are an administrator of the host. So, this behavior only applies to users who already have access to the VM.
However, we take this feedback very seriously, and we are reevaluating this design decision for the next dot-release of Workstation.
For further questions regarding this issue or other security related issues for VMware, please contact us at security@vmware.com.
