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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek