Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Bugtraq
[Top] [All Lists]

RE: VMWare poor guest isolation design

Subject: RE: VMWare poor guest isolation design
Date: Thu, 23 Aug 2007 23:16:17 -0800 (AKDT)
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

<Prev in Thread] Current Thread [Next in Thread>