Bugtraq mailing list archives
RE: More on VMWare poor guest isolation design
From: "M. Burnett" <mb () xato net>
Date: Mon, 27 Aug 2007 11:51:46 -0600
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. 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. 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. 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. Mark
-----Original Message----- From: Tim Newsham [mailto:newsham () lava net] Sent: Saturday, August 25, 2007 1:05 PM To: M. Burnett Cc: 'Arthur Corliss'; 'Jonathan Yu'; bugtraq () securityfocus com Subject: Re: More on VMWare poor guest isolation design2. This issue is not about a user on the host compromising a virtualguest.It is about a *non-privileged* user on the host being logged in toguestmachines as an administrator, and a worm--running in the context ofthatnon-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-privilegeduser on the host, there will be limits on what this user could do to accomplish some of the other attacks mentioned.Your position seems to be that an easy automated scripting interface is a lot more dangerous than a slightly harder indirect attack method. The truth is that they are both scriptable and reliable. Techniques for attacking virtual machines from the host are certainly no harder to code than the average remote exploit that worms used to propogate. Do you really think a worm writer who wants to compromise VMWare guests would take advantage of a scripting interface but shy away from the task if he had to write custom code to break into the guest?4. This is also not so much about this specific issue at hand--we caneasilyblock this--but also looking at the bigger picture of establishingbestpractices for dealing with the guest/host relationship.Here's a best practice: Don't assume that guests are protected from software running on the host system.As a side note, I specialize in hardening Windows so all of thesesystemshave been hardened with my own hardening script that is quiteextreme. Theseare by no means weak targets.A (virtual) machine where attackers can arbitrarily read and write the memory, the disk and even alter devices is going to be a soft target. The physical analogy that someone brought up earlier works well here. Would you consider your machine locked down if someone could open your computer case, yank the hard drive and attach new devices to the system at will? Well, with a virtual machine they can do that while the machine is running.Mark Burnett http://xato.netTim Newsham http://www.thenewsh.com/~newsham/
Attachment:
smime.p7s
Description:
Current thread:
- RE: VMWare poor guest isolation design, (continued)
- RE: VMWare poor guest isolation design M. Burnett (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design William Holmberg (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design James C. Slora Jr. (Aug 24)
- Re: VMWare poor guest isolation design Jonathan Yu (Aug 24)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- Re: VMWare poor guest isolation design Jonathan Yu (Aug 24)
- More on VMWare poor guest isolation design M. Burnett (Aug 25)
- Re: More on VMWare poor guest isolation design Tim Newsham (Aug 27)
- RE: More on VMWare poor guest isolation design M. Burnett (Aug 27)
- RE: More on VMWare poor guest isolation design Tim Newsham (Aug 30)
- RE: More on VMWare poor guest isolation design Arthur Corliss (Aug 30)
- RE: VMWare poor guest isolation design M. Burnett (Aug 24)
- Re: More on VMWare poor guest isolation design Wietse Venema (Aug 27)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 25)
- RE: VMWare poor guest isolation design Ken Kousky (Aug 27)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 30)