RE: VMWare poor guest isolation design
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 autostart
capability 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