You may or may not be aware that I have just moved house, and, me being me, I have not done it by halves. My family and I up’d sticks to the other side of the world, and we landed in Perth—not Scotland, but Australia. Call it a cross-cloud migration; this obviously was fraught with difficulties and did not go as smoothly as planned. This has got me thinking about moving home in a cloud environment, whether from site to site, region to region, or cloud provider to cloud provider. In a perfect world, this should be as simple as live migration is today between like-minded virtualization hosts: VMware to VMware, Hyper-V to Hyper-V. The unfortunate truth is that this is not the case.
Articles Tagged with Qemu
Since the early days of virtualization, people have theorized about the capability of an “escape the VM” type of attack. This is a hacker’s nirvana: to take over a running virtual guest and use it as a base from which to attack the underlying virtual host.
There is quite a bit of documentation on bare metal or Type 1 hypervisors, including my own book, VMware vSphereTM and Virtual Infrastructure Security: Securing the Virtual Environment, but there is not much material on the proper security of hosted environments, or Type 2 hypervisors, such as Microsoft Virtual Server, VMware Workstation, Fusion, Player, or Server as well as Qemu, Virtuozzo, or OpenVZ.
There is an interesting discussion about this on the VMware Communities on just this subject. It is interesting given the vulnerability being discussed is CVE-2009-1244 (or VMware’s ID VMSA-2009-0006) which relate to Guest Operating System driver vulnerabilities in hosted environment. It relates specifically to paravirtualized video drivers allowing the possibility of code to run within the host from within the Guest OS. In other words, escaping the VM.