Keeping Your VMotion Traffic Secure

From the VMware Security Blog: Keeping Your VMotion Traffic Secure.

Recently a researcher published a proof-of-concept called
Xensploit which allows an attacker to view or manipulate a VM undergoing live
migration (i.e. VMware’s VMotion) from one server to
another. This was shown to work with
both VMware’s and Xen’s version of live migration. Although impressive, this work by no means
represents any new security risk in the datacenter. It should be emphasized this proof-of-concept
does NOT “take over the hypervisor” nor present
unencrypted traffic as a vulnerability needing patching, as some news
reports incorrectly assert. Rather, it a
reminder of how an already-compromised network, if left unchecked, could be
used to stage additional severe attacks in any environment, virtual or
physical. …

Encryption of all data-in-transit is certainly one well-understood mitigation
for man-in-the-middle attacks.  But the fact
that plenty of data flows unencrypted within the enterprise – indeed perhaps
the majority of data – suggests that there are other adequate mitigations. Unencrypted VMotion traffic is not a flaw,
but allowing VMotion to occur on a compromised network can be. So this is a good time to re-emphasize hardening best practices for VMware
Infrastructure and what benefit they serve in this scenario.


0 comments have been added so far

  1. I’d just like to say “here, here”. I speak about virtualization on a regular basis, and one the things that I reiterate is that people must remember that existing scenarios, for example, data center servers using publicly exposed LANs, are looked upon as the fault of virtualization if something bad should occur. This is why it is ever important to still plan precociously when it comes to virtualization. Even if it is not virtualization’s fault, it tends to get blamed regardless.

  2. News Flash: If You Don’t Follow Suggested Security Hardening Guidelines, Bad Things Can Happen…

    The virtualization security (VirtSec) FUD meter is in overdrive this week…Part I: So, I was at a conference a couple of weeks ago. I sat in on a lot of talks. Some of them had demos. What amazed me about

  3. Indeed, some of the media coverage was somewhat inaccurate. When I spoke to some of the press, I really wanted to emphasize the awareness of the issue but not hype it up or pretend like it’s some doomsday scenario by any means. In particular, with regards to “taking over the hypervisor”, we showed how an in-progress migration could be manipulated by a MITM attacker in order to exploit vulnerabilities in the migration routines of the Xen dom0 daemon. So to clarify, the MITM manipulation of VM state/memory applies to both Xen and VMware migrations, but the remote hypervisor exploits only apply to Xen <= 3.1.0.
    Andrew: I believe this is one of the scenarios where virtualization is indeed to blame. One of the underlying themes of my presentation is that we've been continually breaking down isolations barriers that provide security in exchange for new functionality. We've gone from physical machines where state is protected by hardware mechanisms such as the MMU, to virtual machines where the machine state is protected by the isolation boundaries of a software layer such as the VMM/hypervisor (which, as we've seen, often fails in its isolation), to VM migration where the machine state is exposed to the local network and any attackers who happen to be snooping. This transition isn't necessarily a bad thing…we just have to be aware of the security concerns it presents.

  4. Jon: Good points. Although I think perhaps I overstated my position. I simply mean to say that private management networks, segregated LANs for datacenter servers, RFC 1918 space — these area all practices that we should already be implementing. If you are running your servers on the “internet”, and then use one of these links for VMotion traffic, (even if the link is direct and not wide), you’re not practicing bad VMotion implementation, you’re practicing bad networking. Keep your networks private and secure unless otherwise needed.
    That said, have you thought about implementing IPSec in the ESX kernel? This should shut some people up.

Leave a Reply

Your email address will not be published.