bugtraq - Re: VMWare poor guest isolation design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0708232353500.816@AncHm-1.nevaeh-linux.org>
Date: Fri, 24 Aug 2007 00:13:37 -0800 (AKDT)
From: Arthur Corliss <corliss@...italmages.com>
To: Jonathan Yu <jonathan.i.yu@...il.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: VMWare poor guest isolation design

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.

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