Message-ID: <Pine.LNX.4.64.0708232316430.816@AncHm-1.nevaeh-linux.org>
Date: Thu, 23 Aug 2007 23:50:51 -0800 (AKDT)
From: Arthur Corliss <corliss@...italmages.com>
To: "M. Burnett" <mb@...o.net>
Cc: bugtraq@...urityfocus.com
Subject: 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

Powered by blists - more mailing lists