On 8/24/07, Arthur Corliss <corliss (at) digitalmages (dot) com [email concealed]> 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
>

[ reply ]