RE: More on VMWare poor guest isolation design

On Mon, 27 Aug 2007, M. Burnett wrote:

> I should probably have already ended this discussion, but it reminds me of a
> discussion I had on this same list almost ten years ago trying to explain to
> Microsoft why a vulnerability that discloses physical paths is a big enough
> deal to bother patching. Their argument was that they couldn't see the risk
> of disclosing a physical path, and if someone could do something with that
> path then they could probably discover the path in the first place. My
> argument was that it really doesn't matter what the current risks might be,
> that's really not the point, let's just fix it anyway. It turns out later
> there were a number of IIS issues where people could execute or access
> files, but they needed to know the physical path first.

Dude, you're talking about apples and oranges. Path disclosure in a web app is bad, period, and should be considered a security risk. But the API you're complaining about is a *legitimate* feature with legitimate uses. Yes, it's a feature that can be very badly abused, so enabling it needs some forethought and intelligence.

I've said this once already, but it bears repeating: your concerns deserve discussion in context of vmware best practices. But I personally don't believe it merits discussion as a vulnerability. It's no more a vulberability than, say, not setting a password on your Windows administrator account. It's obviously idiotic, but not a flaw in the software stack.

> I think some of you are overanalyzing this issue. I am well aware that there
> are other ways to accomplish the same thing in many instances, I am not
> saying I have introduced a spectacular new attack vector. I would categorize
> this threat standing on its own as medium to low, depending on your
> environment. But the fact is that this thing bypasses normal OS security
> mechanisms and we simply cannot imagine how that might be used by an
> attacker in the future. Some of you keep trying to point out that owning the
> host always means owning the guests, but that isn't always the case,
> especially if you are not a full administrator on the host machine.

*If* you can use the API to spawn a process in a vm owned and operated by another user *then*, and only then, do you have a legitimate vulnerability. But you're basically complaining about being able to shoot yourself in the foot. It is still incumbent on the host admin to prevent unauthorized access, and *you* to prevent unauthorized use of your account. If those two imperatives are competently met, then vmware's functionality is of little concern.

> I know that for a lot of years people have been saying that once someone can
> access the physical box, there's nothing more you can do. Well, that's just
> not true anymore. You very well can protect a physical machine and you
> should be able to protect a virtual guest from its host. There's no way a
> non-admin user is going to be able to modify the RAM of a vm. And in Windows
> Vista, if not already blocked, even as an administrator I would have to
> explicitly allow a worm to access the RAM or disk of a virtual machine. No
> worm is going to access a vm's resources without a UAC prompt coming up.

You've got a lot more confidence in Vista then I do. Regardless, here's the practical reality: you have a unprivileged process which can send commands to control a vm running with privileged resources, right? As someone else pointed out: why not just pause the VM (which writes the vm address space to a *user*-owned file), edit it, and restart it? I'd be very surprised if there wasn't more that could be done to a live vm as well.

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

Anyway you cut it, UAC is worthless in this circumstance.

> The argument that owning a physical machine automatically means game over
> just isn't true. We should be able to say the same thing about a VM.

I'm sorry, but your expectations for the use and value of virtual machines is very much out of step with reality.

 	--Arthur Corliss
 	  Live Free or Die