Bugtraq mailing list archives
RE: VMWare poor guest isolation design
From: "M. Burnett" <mb () xato net>
Date: Thu, 23 Aug 2007 14:30:49 -0600
You are correct that this isn't an issue for everyone and you are correct that this isn't an issue if reasonable security practices are employed. On the other hand, most security issues reported here wouldn't be issues if reasonable security practices were employed. I have been saying that for years. Because it does not apply to your particular environment doesn't invalidate the issue. There are many, many situations where someone would want to access a vmware guest via the console and not allow any network access at all. One that comes to mind is an offline root CA that you can only fire up only when you need it--a virtual offline machine. Another situation for myself is I keep all my hacking/pen-testing tools on a vm that I can use when I need them, and quickly move to any vm host I need to run them on. I don't necessarily want to make that virtual machine accessible from the network. Anyway, it is absurd to say you will never log in to the console, sometimes you just have to. Whether it affects you personally or not, it certainly is helpful to know that the capability exists so you can make better informed security decisions--and that there is an undocumented switch to disable that feature. Addressing some other points:
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.
This isn't completely true. Yes, it is much more difficult to secure a virtual machine that way, but it can be done. You could, for example, use full disk encryption to prevent someone from mounting a virtual disk outside the guest OS. Besides, I concede that point in my article, emphasizing that an automated attack increases the seriousness of the problem.
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.
VMWare constantly reminds you that you don't have the vmware guest tools installed. I'd say that most people do install them. But that doesn't matter anyway because you can just use the VIX API function VixVM_InstallTools to install them if they aren't already there. And you do not need to be logged in, the VIX API allows you to wait until the command actually runs. So it can just sit there until the next time you do login to the console. Mark Burnett http://xato.net
-----Original Message----- From: Arthur Corliss [mailto:corliss () digitalmages com] Sent: Thursday, August 23, 2007 10:49 AM To: M. Burnett Cc: bugtraq () securityfocus com Subject: Re: VMWare poor guest isolation design On Wed, 22 Aug 2007, M. Burnett wrote:I have run across a design issue in VMware's scripting automation APIthatdiminishes VM guest/host isolation in such a manner to facilitateprivilegeescalation, spreading of malware, and compromise of guest operatingsystems.VMware's scripting API allows a malicious script on the host machinetoexecute programs, open URLs, and perform other privileged operationson anyguest operating system open at the console, without requiring any credentials on the guest operating system. Furthermore, the scriptcanexecute 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, butlogged into guest operating systems as an administrator, the script running asanon-admin on the host can still execute admin-level scripts on theguests.I obviously did not discover this issue--the API developers providedit as afeature-I am simply pointing out the potential danger, that it was apoordesign decision, and that there is a need to establish best practicesforvirtual 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. 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. 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. In (not so) short, this attack vector is virtually worthless if reasonable security practices are employed. --Arthur Corliss Live Free or Die
Attachment:
smime.p7s
Description:
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: VMWare poor guest isolation design M. Burnett (Aug 24)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 23)