Message-ID: <020e01c7e6b7$750a2030$5f1e6090$@net>
Date: Fri, 24 Aug 2007 19:29:57 -0600
From: "M. Burnett" <mb@...o.net>
To: "'Arthur Corliss'" <corliss@...italmages.com>,
	"'Jonathan Yu'" <jonathan.i.yu@...il.com>
Cc: <bugtraq@...urityfocus.com>
Subject: More on VMWare poor guest isolation design

I hate writing such a long post here, but I think it's important that I
clarify some points:

1. Of course this won't issue won't affect everyone, especially if you are
using vmware mainly for hosting server roles and especially if you do not
run the client utilities, but even if it affects 10% of the people out
there, it is still an issue. Remember the MSBlaster worm? At it's peak it
had only infected about 150,000 systems--a very small percentage of Windows
machines.

2. This issue is not about a user on the host compromising a virtual guest.
It is about a *non-privileged* user on the host being logged in to guest
machines as an administrator, and a worm--running in the context of that
non-privileged user on the host--being able to access the admin-level
context of the guest machines without knowing those administrator
credentials. Also remember that since I am talking about a non-privileged
user on the host, there will be limits on what this user could do to
accomplish some of the other attacks mentioned.

3. It's not just the ability to access the guest OS's that is significant
here, it's the *automated* access that is key. There are endless ways you
could own a guest OS manually. But with the API just a few lines of code
could enumerate all open guests and execute commands in each. This attack
requires no interaction or trial-and-error in attacking the guest OS's, nor
does it require any login credentials on any guest OS. This is all
significant because it would be an easy way for an automated (and
lightweight) worm to propagate. This isn't so much about guest OS compromise
as it is about malware propagation.

4. This is also not so much about this specific issue at hand--we can easily
block this--but also looking at the bigger picture of establishing best
practices for dealing with the guest/host relationship.

5. Arthur, it may not affect you but the way you use virtual machines is
likely not representative of the population of vmware users.

6. The argument that a secured server won't be vulnerable is fine, but
that's a pretty big assumption to make. There are few vulnerabilities ever
found that couldn't be reasonably anticipated and prevented by following
long-established security best practices. But somehow people still keep
getting hacked or infected. So yeah we could stop this stuff if everyone was
secure but they aren't.


Finally, let me explain how I personally use virtual machines to put this
all in context of why I think this is important. I use Windows Vista as my
host machine, logged in as a non-admin user. I am typing this e-mail--also
as a non-admin user--in a Windows XP virtual machine dedicated to instant
messaging and e-mail. On another monitor I have a VM running Windows 2003 as
a domain controller (btw, you need the client utilities on domain
controllers to keep the clock correct) where I am logged in as an
administrator, but the screen saver is password-protected and I lock the
console anyway when I am finished using it. On that machine I have a number
of admin and networking tools installed. Finally, I have yet another Windows
XP virtual machine running with a lot of my pen-testing tools. Many of these
just don't work well unless you are an admin, so I am logged in as an admin.
That machine is "paused" and I start it up when I need it. I probably have a
dozen other specialized machines paused for different client projects I am
working on. 

As a side note, I specialize in hardening Windows so all of these systems
have been hardened with my own hardening script that is quite extreme. These
are by no means weak targets. I also make sure the guest machines are fairly
isolated by not allowing shared drives or drag/drop between machines.
Remember that so far there has been no security reason not to run the client
utilities, and using a windows guest really sucks without having them
installed. 

Since I do much of my web browsing on the Vista host machine, I thought this
whole setup was a secure way to isolate everything. I keep my browsing,
communications, client work, and administrative tasks on isolated machines.
However, if a worm were somehow able to run on my Vista host, it could
likely  compromise all the other guests OS's including those where I am
logged in as an admin, and it could do it in seconds with just a tiny
payload of just a few lines of code. So running a script as a non-admin user
could mean my whole network is owned in seconds. 

It doesn't matter how secure all my guests are or that I use extremely
secure passwords or that I am current on all my patches or I am running a
super-tight firewall on each guest. A single API call bypasses all of that.
A script wouldn't even need to know the administrator's name, which isn't
administrator on all my systems, it just runs commands as whatever user has
logged in to the console. Locking the guest OS screens or having a
password-protected screen saver doesn't help any either, the code still
runs.

So you can see that there are many different ways that people user virtual
machines. Not just as servers, but as workstations as well. And not just
linux, but Windows too. A prudent administrator has no reason to expect a
guest machine to become vulnerable just by installing the guest utilities.
There has been no reason to think that being logged in as a non-admin user
on the host could still result in a compromise of the admin credentials in
the guest OS's. 

But now there is.



Mark Burnett
http://xato.net








Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (2805 bytes)

Powered by blists - more mailing lists