VMWare security hole - it sounds like you need the patch, even if it's not clear why

VMWare just announced a patch for a security hole in its virtual machine software.

The hyper-sized virtualisation company wasn't terribly clear about just how much risk the flaw exposes you to, or quite how badly you might get owned as a result.

So the best bet is probably to patch now and ask the questions later.

The bug was announced in VMSA-2013-0002, VMWare's most recent security advisory. It says simply:

VMware ESX, Workstation, Fusion, and View address a vulnerability in the VMCI.SYS driver which could result in a privilege escalation on Windows-based hosts and on Windows-based Guest Operating Systems.

As you probably know, virtualisation is a mechanism that allows one computer to pretend to be many.

Mainframes have been doing this for about half a century; on commodity hardware, turning one computer into several pseudoservers has only been practicable for about the past decade.

There are many benefits, mostly to do with scalability and flexibility.

It's much easier to add one more guest virtual machine (VM) onto an existing virtual machine server, known as the host, than it is to install and commission a brand new physical server.

→ Starting a new VM, which these days can be as easy as clicking a mouse button, is still referred to in IT jargon by the quaint and anachronistic name of "standing up" a server.

Similarly, you don't face an economic dilemma when you want to stand down a virtual server.

The other VMs, known as guests in IT-speak, each just run a bit faster. You don't end up with a rack-unit of idle hardware and a financial controller making tut-tut noises.

Of course, there are some significant risks in virtualisation, too.

One of them is that your guests are no longer actually separate, as they were when each server was, if this doesn't sound too obvious, a separate server.

Indeed, the guests and the host are usually interconnected by means of a control interface, without which managing multiple guests on a single host would be tricky.

So, you have to assume, or at least to hope, that the control interface doesn't allow for greater interaction between guest and host, or guest and guest, than it ought to.

In VMWare, that interface is VMCI, the Virtual Machine Control Interface.

To quote further from VMSA-2013-0002:

VMware ESX, Workstation, Fusion, and View contain a vulnerability in the handling of control code in VMCI.SYS. A local malicious user may exploit this vulnerability to manipulate the memory allocation through the Virtual Machine Communication Interface (VMCI) code. This could result in a privilege escalation on Windows-based hosts and on Windows-based Guest Operating Systems.

You'll have to ask VMWare exactly what this means, but it certainly sounds as though a user at one end of the host-to-guest control channel can do stuff they aren't supposed to on the other end of the control channel, if the other end is running Windows (and thus the buggy VMCI.SYS driver).

In short, it sounds as though a user inside a guest VM might find himself able to do unauthorised stuff on the host operating system, and perhaps even in other guests.

That's always going to be a security nightmare, not least in a server hosting environment where the guests are outsiders from a range of different companies, and the service provider is relying on VMWare to keep the guests apart, at least from a security point of view.

Likewise, if you have a Windows guest server hosted in a virtual server farm, an unprivileged user at your hosting provider might be able to fiddle around inside your guest operating system. And that probably isn't the level of security you want.

As I said, VMWare has been a bit cagey (if you will pardon the hosted server farm pun) about exactly what this vulnerability means to its users.

So-called local privilege escalations are often of low concern because they require an attacker already to be logged on to the computer.

But if local in this case merely means "running in a guest VM on the host hardware", then such local users must be considered implicitly remote.

Unless and until a clearer explanation of the risks emerges, then, I'd suggest that you "just do it."

Grab the patch and apply it...