bugtraq - RE: VMWare poor guest isolation design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 Aug 2007 23:16:17 -0800 (AKDT)
From: Arthur Corliss <corliss@...italmages.com>
To: William Holmberg <wholmberg@...pi.com>
Cc: "M. Burnett" <mb@...o.net>, bugtraq@...urityfocus.com
Subject: RE: VMWare poor guest isolation design

On Thu, 23 Aug 2007, William Holmberg wrote:

> Arthur,
> Perhaps there are implementations in certain businesses that require
> those things. It is possible you may not be the only person with that
> level of access, particularly in a large environment with 50 or so DA's,
> and 10's of 1000's of users, with dozens or hundreds of VM's...
>
> Looked at in the perspective that you don't *own* the hardware and the
> VM's on them, would that alter your answer at all?

I think a realistic example would be a mass hosting company where your vm
resides on a server with other potentially hostile vms.  First off, you're
not vulnerable via this technique by those other users.  Guests can't spawn
processes in the host OS.

So, the only risk is the from your hosting company's admins, and any
rational person would have already evaluated the assumption of risk and
chosen to *not* place sensitve, proprietary data on that box in the first
place.  Remember, you have no physical security at that point, so all bets
are already off.

But, say you can accept that risk -- you can still eliminate that attack
vector by a) not running the guest utilities *or* b) not logging onto the
(virtual) local console.  Please correct me if I'm wrong, but that's a
prerequisite in order for this to work, because the listening agent for
those commands runs as a userland process.  Use ssh or RDP (and if you're
using RDP w/Windows then for god's sake *disable* the guest utilities,
because they provide *no* value for remote connections).

In this scenario I still don't believe this is an issue, especially since
it's that easy to disable.

Extending this to an internal corporate platform changes nothing.  In a sane
deployment the large groups of admins would only have access to vms, not the
host platform.  Only a select group of admins would have access to the host
OS, and then common security practices of logging & auditing applies.  The
number of potential abusers are minimal, and with remote logging to servers
under the security team's control the ability to cover their tracks is
extremely difficult.

Am I missing something, or is this still much ado about nothing?  I agree
that that functionality should be very clearly labeled, and probably beyond
what vmware currently does.  But overall, this is a very easily managed
vector.

 	--Arthur Corliss
 	  Live Free or Die