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

Filed Under: Featured, Vulnerability

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...

Image of server rack courtesy of Shutterstock.

, , , ,

You might like

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

  1. JimboC_Security · 967 days ago

    Thanks Paul for the info about this patch. When I first encountered this security advisory last Friday I was a little surprised when I saw the solution (in my case) was to upgrade to VMware Workstation 9.0.1 which I had already done some time ago.

    VMware Workstation 9.0.1 has been available since early November 2012 and I had upgraded from 9.0.0 to it immediately since I noticed the following in the release notes (this particular change was also present in the VMware Player 5.0.1 release notes):

    “Several security vulnerabilities have been addressed, including updating third party libraries”.


    By default VMware Player is installed with VMware Workstation. If you are using Workstation or Player the above information should provide even more reason to upgrade.

    I hope this helps. Thank you.

  2. Joshua Gregory · 967 days ago

    "referred to in IT jargon by the quaint and anachronistic name of "standing up" a server"

    "known as guests in IT-speak"

    I'm confused why you wrote an article that applies to VMware administrators with phrases that try to explain the architecture to someone who's never used a server?

    • Steve · 967 days ago

      Mind if I reply for you, Paul?

      Short answer: Because he can, and because we appreciate it.

      There are some of us who don't think we already know all there is to know, and enjoy expanding our knowledge base. So we read things that may not necessarily apply to us directly at that point in time.

      Thanks to Paul, Graham et al for their exemplary efforts to help ALL of us.

      (and I'm confused why anyone would even question them on that point!)

      • Nigel · 966 days ago

        What Steve said.

        I operate a server, and although it doesn't use VMware and I'm not particularly interested in its architecture, I'm able to generalize and synthesize information that improves my overall understanding of processes and operations for which I have assumed responsibility. In other words, I can learn useful things by understanding other things that don't necessarily apply directly to me.

        Security should be everyone's concern. Obscuring it behind jargon and geek-speak doesn't serve that purpose. I appreciate the care and consideration that Paul, Graham, and most of the other NakedSecurity bloggers take in making their articles understandable to non-experts.

    • Paul Ducklin · 967 days ago

      Thanks for the kind words, @Steve :-)

      There's also the fact that the article applies to any and all VMWare users, including those with the Workstation and Fusion products...and many of those users aren't admins.

      (And that I have a suspicion that some of the younger admins amongst us may never have used "separate servers", and thus might not be aware of old-school server architecture. And some admins may only ever have used servers running as guests on other people's VMWare hosts, and thus have been shielded from the details of what happens on the server iron itself...)

      • Joshua Gregory · 966 days ago

        I understand. Sorry for the assumption.

        • Paul Ducklin · 966 days ago

          No worries.

          IMO, the terms "host" and "guest" *are* confusing, since guest can refer to a logged-in remote user, and also to a locally-running copy of an entire OS (which can be identical to the one on the host itself :-).

  3. Rico R · 967 days ago

    I think I know what is going on here. To me, privilege escalation means that a process can run as administrator without permission or knowledge of the user. This allows for several malicious exploits to occur. You may now ask, "How can a virtualization software allow that to happen?" Simple: I know from experience with Windows built-in parental controls that when VMware is installed, it adds a hidden user called VMware__user or something like that. This user is hidden not like the built-in administrator account, as it is hidden to everything in Windows except the parental control panel. I predict that when this user is used by the software in such a way that it can access more low-level areas of a computer system only through that administrator account. The only catch to this account... it's password protected. VMware must be programmed to use the correct password to do it, but the exploit that VMware is patching would allow non-VMware code to use this account for malicious purposes. So, VMware released this mysterious patch to prevent that from happening.

  4. Bob · 966 days ago

    With Fusion v.4, it seems the maintenance release from Nov2012 is still the latest and includes this patch. Your article led me to believe there was a new patch for that version as well, and had me concerned for a while that I couldn't find it.

    -An admin who understands "standing up a server" because we used to have to lay them down to install RAM and wire up hard drives, and who uses Fusion on his laptop.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog