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
