Now that you have a good overview of the Hyper-V architecture, we should say a few words about security. After all, you can now run multiple computers on the same hardware, separated only by a thin layer of hardware and software. If one of the partitions gets compromised, what could it do to the others? It could attack the hypervisor and, if it succeeds in compromising it somehow, attack the other partitions. In other words, the hypervisor is the key to the whole thing. Hyper-V was designed with such security issues in mind. We’ll cover what was done to make an attack as hard as possible, but keep in mind that no sane person could ever guarantee 100 percent that an attack from one VM to the other through the hypervisor is impossible. It is software, and any piece of software has bugs.
As discussed, the Hyper-V hypervisor was designed to have a small footprint. That by itself is good for security: the less code and complexity, the better. Also, the Hypercall APIs that are needed to talk to the hypervisor are open to public scrutiny. Therefore, Microsoft had to make the assumption that all possible Hypercall functions are accessible to attackers and took measures to protect against invalid arguments, bad usage, and so on.
A basic premise of the Hyper-V security model is that the parent must be trusted, both by the hypervisor and by the child partitions. After all, all system resources are controlled by the parent. For instance, if an attacker controls the parent partition, he or she can stop and start VMs at will, inspect their disks, and so on. Given that premise, the Hyper-V architecture has to defend against two avenues of attack against the parent: external and internal.
An external attack against the parent is nothing more than a normal hacking attack: guess a password, try to compromise a running service, intercept management traffic, and so on. To minimize the attack surface, we recommend you use a Windows 2008 Server Core or the dedicated Hyper-V Server edition for the parent and use only the strict minimum of services required. Don’t fall into the temptation of using it for a file server, domain controller, or any- thing else. If it’s not related to Hyper-V functionality, it needs to go into a VM.
An internal attack would have to come from a compromised child partition, using Hyper-V resources such as the VMbus, VSC, or Hypercall API to try to attack services in the parent parti- tion. Also, an attack from one VM to another VM on the same host would constitute an internal attack. To illustrate the principle, take a look at Figure 29.24.
Each dashed line represents a security boundary, either as a ring transition in the CPU or the software separation between partitions. To defend against an internal attack, the Hyper-V architecture has implemented the following measures:
The hypervisor uses unique resource pools for each partition. In other words, no VM-specific
•u
data is shared with other VMs. Such data cannot be used for a direct attack. Along the same line, no memory is shared between VMs. Each VM has its own memory space.
There is no direct communication from one child to another. All communication either
•u
goes through the parent or goes through a really external medium such as the network. Each child has its own VMbus instance to the parent. So, even if one VMbus instance is
•u
compromised, this has no direct influence on other child partitions.
Each child has its own controlling process in the parent, a VM worker process, as noted
•u
earlier.
DMA attacks between VMs are not possible because a child partition can never own a
•u
physical device.
There’s more. Architecture is one thing; actual coding is quite another. The programmers of the hypervisor have taken steps to make an attack as difficult as possible and to try to detect an attack if it happens. Some of these include the following:
The hypervisor uses Address Space Layout Randomization (ASLR) whenever possible.
•u
This is a technique where different pieces of code are always loaded at different addresses. Figure 29.24
The dashed lines are security boundaries in a Hyper-V machine. VM Service VM Worker VSP Kernel Applications Applications Parent
Partition PartitionChild PartitionChild
VSC
Kernel KernelVSC
Ring 3
Ring 0
Ring -1 Hypervisor: VMBus Host, Memory
This makes buffer overrun attacks very hard, since those depend on a predictable starting point for executable code.
Hardware Data Execution Prevention is mandatory, meaning that only in-memory code
•u
that is marked as executable can actually be run. This protects against stack overflow attacks. In addition, memory pages containing code are marked as read-only. Any attempt to modify such data should generate a blue screen.
Stack Guard cookies are known pieces of data on the stack that the hypervisor uses with
•u
certain internal functions. If these cookies are modified, the system will know there has been a stack overflow or an illegal but successful modification of the stack. A blue screen will probably be the next event.
Last but not least, the hypervisor file is digitally signed. Any attempt to modify it offline
•u
will stop it from loading.
All of these countermeasures against internal attacks are no guarantee that an attack cannot succeed. But they do indicate that Microsoft has taken security very seriously.