Bugtraq mailing list archives
Re: VMWare poor guest isolation design
From: "Jonathan Yu" <jonathan.i.yu () gmail com>
Date: Fri, 24 Aug 2007 09:51:51 -0400
On 8/24/07, Arthur Corliss <corliss () digitalmages com> wrote:
On Thu, 23 Aug 2007, Jonathan Yu wrote:Hi there, First of all - please forgive me, I'm not a developer and I don't use the automation API. However, I use VMware a lot for development. I have a Windows XP host machine and I use VMware to develop Linux code (Debian Etch, Linux 2.6).I'm a p570 user on the server side, but I do use vmware workstation for development purposes as well.It is worse than this because according to the original e-mail, you can queue up commands to be executed upon the next login. That is where it gets dangerous, whereas it wouldn't have been an issue with "no physical security" alone.Only if you *choose* to run the userland utilities. If you don't, all the queuing in the world won't get those commands executed.However, I propose an alternate attack scenario: if the host system is compromised, then the program is able to write to the VMware Disk files or the physical partition that the virtual machines are installed in. This means that you can write arbitrary things to it or change files around, so you can have the same effect if you, say, add a command to the root user's crontab...Which is my point. If you don't have security on the host, you're already massively vulnerable regardless of whether or not this functionality exists.Furthermore, this attack only works if you are running the vmware guest utilities *and* you are currently logged into a GUI desktop running the vmware userland process.Many people are in this situation.So we're surrounded by lemmings. You're not pinning that on me, man. ;-)I have all the guest tools installed. Why? It is useful - besides the hgfs ("Shared Folders") support, there is also the vmmemctl module, which returns unused memory pages back to the host OS, which allows overcommitting if necessary (on my system it just ensures that I can use as much of the RAM as possible).I'm glad you're getting some utility from them, you're part of the demographic they wrote them for. But, odds are, you're also part of the demographic that still doesn't have practical impact by this. You probably admin your own box as well as the vms you develop in. If your host has gotten exploited, whether or not they can execute something in a vm is the least of your problems. Once again, host security rules all.
Agreed. And this is the important part. Even if people are using an "enterprise-class" solution such as OpenVZ (which shares a Linux kernel with many virtual environments) or the VMware ESX Server (which, if I recall correctly, runs its own operating system on the host machine).
Let's sum this up, folks: this functionality poses no threat to the host platform. So, if someone cracks the *host* isn't that fact alone far more frightening than the ability to (maybe) launch a few processes in a vm? I'd wager that the damage that can be done by launching a few processes on the host is far more gruesome than what can be done in the guests. --Arthur Corliss Live Free or Die
Current thread:
- VMWare poor guest isolation design M. Burnett (Aug 23)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 23)
- 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 23)
- Re: VMWare poor guest isolation design Arthur Corliss (Aug 24)
- RE: VMWare poor guest isolation design Arthur Corliss (Aug 25)