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  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

Powered by blists - more mailing lists