Bugtraq mailing list archives
RE: VMWare poor guest isolation design
From: Arthur Corliss <corliss () digitalmages com>
Date: Thu, 23 Aug 2007 23:50:51 -0800 (AKDT)
On Thu, 23 Aug 2007, M. Burnett wrote:
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.
Amen.
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.
No offense, but regarding your offline root CA -- doesn't hosting the vm on a network-connected machine kind of defeat the purpose? That's only two degrees from massive insecurity, this vector isn't the biggest problem you have. As to having to sometimes log into the console, I didn't say it was absurd, but I did point out that it was trivial to disable the threat if you do: don't run the guest utilities. Problem solved. And, quite frankly, how much value do the guest utilities really provide? Is there a single application you can think of that needs it in order to run? If it did then you've found where the emulation and virtualization wasn't complete.
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.
I agree with you whole-heartedly here. This functionality should be very clearly labeled. But I would stop *way* short of saying that this was flawed or bad design. It has its place, and for (yes, this is a SWAG) 80% of the installations out there it has genuine utility and zero danger. Most installations probably have the same administrative staff managing both the platform and the vms. It's our *right* to shoot ourselves in the foot. ;-)
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.
An encrypted filesystem really only protects you from someone doing offline analysis, it does absolutely nothing for an attacker who can monitor memory directly. Regardless, that risk exists regardless of the functionality we're discussing here. And I don't see that functionality exacerbating this fundamental insecurity. Any way you cut it if you can't trust the host OS or the admins who control it, this is the least of your problems.
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.
Actually, that only works in the best of circumstances. It assumes that the guest is already running an automounter process and some sort of autostartcapability or system call exposure. This just goes to show how terribly (and absurdly, to steal your adjective) insecure many OS'es are out of the box. That function is completely nonfunctional with my guest OS'es.
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.
That sounds a lot like a blocking call to me, not a queuing mechanism, which would suggest to me that the calling process needs to be actively running (and waiting) until you do log in. In case I've misunderstood, I'll spot you a fire & forget queue'ing mechanism, and still not be concerned. You still need that userland process to perform the system call. If you don't run it (or, if you do remote administration via a access method that doesn't start it when you log in) it will never execute. Before you think I'm just being obtuse or obstinate, please understand that I agree with you that if everyone goes by the default suggestions they're screwed. I just think the screwing has more likely begun long before the guest utilities are installed. I also think you raise a lot of good points, but don't think it necessarily should have been raised on a security/vulnerability list. It definitely belongs in any discussion on vmware best practices, though. --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: VMWare poor guest isolation design M. Burnett (Aug 24)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 23)