A virtual machine manager can be a useful starting point for an attacker. In this video, you’ll learn how VM escapes and resource reuse can be maliciously used by an attacker.
With today’s cloud-based infrastructures, we can build virtual machines at a moment’s notice, and we can build many virtual machines simultaneously. If you’ve ever managed a laptop computer or a desktop computer, you know what the security concerns might be for a device like this. But if you’re managing a cloud, you may have situations where virtual machines are constantly created and torn down during a normal workday. This makes it more challenging to manage the security posture of these virtual devices.
Consider also that these virtual machines may all be built with different configurations. These virtual machines might all have a different number of CPUs operational, and those CPUs may have different capabilities. They might have a different amount of memory or different amount of storage. And each one of these systems may be slightly different in how it operates. And of course, these virtual machines do have aspects of the VMs that are very similar to OSes you may be running with other physical devices.
So the VM does run a version of an operating system, such as Windows or Linux, and you should be applying the same type of security best practices to your virtual machine as you have to your physical devices. But there are some security vulnerabilities that are specific to the virtual world. Vulnerabilities such as a local privilege escalation, command injection, information disclosure, and others can still be found in these virtual environments.
If you’ve ever used a VM, you know that that VM is its own self-contained system with its own CPU, memory, storage, and other resources. And it’s not possible to somehow move from inside one virtual machine on a hypervisor to things that may be on a different virtual machine on that same hypervisor.
However, there have been instances where researchers have found ways to jump between these VMs. This is called a VM escape, and it allows the attacker to get access to one virtual machine and then somehow find their way to connect to other virtual machines on that same hypervisor. Some hypervisors may manage tens or even hundreds of different virtual machines, which means if you can escape from one VM and move to another VM on that same hypervisor, you would have a great deal of data that you would be able to access.
This would obviously be an enormous exploit that would allow an attacker to gain access to many systems simultaneously and all of the data contained within those systems. A practical example of a VM escape occurred in March 2017 at the Pwn2Own competition. This is a hacking contest where if you can pwn the device, then you would be able to physically own it. You get to take that laptop or that computer with you at the end of the contest.
In this competition, attackers were able to use a bug in the JavaScript engine of Microsoft Edge to gain access to a sandbox that’s built into the Edge browser. From that sandbox, they were then able to exploit a vulnerability within the Windows 10 kernel. This allowed them to gain full access to that guest operating system. From there, they were able to take advantage of a hardware simulation bug within VMware and hop from one VM to another VM within that same hypervisor.
Fortunately, this vulnerability was only demonstrated for the first time during this competition, which allowed VMware to have some time to create a patch, roll out that patch, and make sure that no one else could take advantage of this VM escape. Another security concern for virtual machines is a resource reuse.
Let’s consider what a hypervisor is doing for all of the virtual machines connected to a particular piece of hardware. The hypervisor is managing this relationship between the physical world and the virtual world. So the hypervisor is allocating a certain amount of memory to one VM, a certain amount of storage, and a certain amount of network and CPU access. Although the hypervisor is allocating this amount of resource use for VM doesn’t mean that VM has exclusive access to that particular resource.
For example, a hypervisor host may have a total of 4 physical gigabytes of RAM on that particular device. But that hypervisor is managing three separate virtual machines, and each of the VMs is allocated 2 gigabytes of RAM each. Obviously, the VMs are allocated 6 gigabytes, and we only have 4 physical gigabytes available for the hypervisor. We’re relying on that hypervisor to only allocate memory where it’s needed, which would allow us to use effectively 6 gig of storage space on a machine that is only equipped with 4 gigabytes.
This means at certain times that there may be certain memory areas that are shared between different virtual machines. And it’s the sharing of information where we could run into a problem. If the hypervisor has a bug that doesn’t properly allow for the sharing of resources, it is possible that one VM could write to a memory area and that memory area could be read by a different VM.
Normally, the hypervisor would be the component restricting that sharing of information between VMs. In this example, we can see that the hypervisor does have some type of memory management issue. Once that code is updated, that particular sharing would no longer take place, and we can avoid any type of resource reuse.