Bugtraq mailing list archives
Re: VMWare poor guest isolation design
From: "Jonathan Yu" <jonathan.i.yu () gmail com>
Date: Thu, 23 Aug 2007 21:06:36 -0400
Hi there, First of all - please forgive me, I'm not a developer and I don't use the automation API. However, I use VMware a lot for development. I have a Windows XP host machine and I use VMware to develop Linux code (Debian Etch, Linux 2.6). On 8/23/07, Arthur Corliss <corliss () digitalmages com> wrote:
On Wed, 22 Aug 2007, M. Burnett wrote: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.I don't see this as a serious problem. This is the virtual equivalent of no physical security. If the host OS (or an account within it) is compromised, of course all bets are off when it comes to a virtual machine running within it.
It is worse than this because according to the original e-mail, you can queue up commands to be executed upon the next login. That is where it gets dangerous, whereas it wouldn't have been an issue with "no physical security" alone. However, I propose an alternate attack scenario: if the host system is compromised, then the program is able to write to the VMware Disk files or the physical partition that the virtual machines are installed in. This means that you can write arbitrary things to it or change files around, so you can have the same effect if you, say, add a command to the root user's crontab...
Furthermore, this attack only works if you are running the vmware guest utilities *and* you are currently logged into a GUI desktop running the vmware userland process.
Many people are in this situation.
I personally look at this as an issue for Windows. I personally don't install the vmware guest software for my Linux VMs, nor would I log into a GUI as root. For that matter, if you are merely hosting the guest VMs why would you need to ever use the vmware console after installation? Use a network-based access method, making the need for the vmware guest utilities unnecessary. That should be sufficient for all OS'es.
I have all the guest tools installed. Why? It is useful - besides the hgfs ("Shared Folders") support, there is also the vmmemctl module, which returns unused memory pages back to the host OS, which allows overcommitting if necessary (on my system it just ensures that I can use as much of the RAM as possible).
In (not so) short, this attack vector is virtually worthless if reasonable security practices are employed. --Arthur Corliss Live Free or Die
Current thread:
- VMWare poor guest isolation design M. Burnett (Aug 23)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 23)
- RE: VMWare poor guest isolation design M. Burnett (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design William Holmberg (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design James C. Slora Jr. (Aug 24)
- Re: VMWare poor guest isolation design Jonathan Yu (Aug 24)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- Re: VMWare poor guest isolation design Jonathan Yu (Aug 24)
- More on VMWare poor guest isolation design M. Burnett (Aug 25)
- Re: More on VMWare poor guest isolation design Tim Newsham (Aug 27)
- RE: More on VMWare poor guest isolation design M. Burnett (Aug 27)
- RE: More on VMWare poor guest isolation design Tim Newsham (Aug 30)
- RE: More on VMWare poor guest isolation design Arthur Corliss (Aug 30)
- RE: VMWare poor guest isolation design M. Burnett (Aug 24)
- Re: More on VMWare poor guest isolation design Wietse Venema (Aug 27)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 23)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 24)