Hardware virtualization is the core concept behind the huge success of cloud computing in the last years. Effective isolation among different virtual machines running on the same host is promised, as well as isolation from the operating system that might be present on the host itself. These barriers are necessary, as cloud computing may create a situation where both provider and customer do not trust each other: The provider wants to keep full control over their expensive server hardware and the customer may want to process sensitive data inside their virtual machine that neither the provider nor other customers are allowed to see. As such, there are several attacker models to be considered in this context, both customers and hosting providers wanting to take control over other virtual machines or the physical server itself. In this paper, we consider attacks for each of the attacker models, as well as possible mitigations. In the end, we will find that while preventing VM escapes only really depends on having secure hypervisor implementations, efforts to protect the VM from the host itself are still rather flawed.
Security Issues in Hardware Virtualization
Abstract. Hardware virtualization is the core concept behind the huge success of cloud computing in the last years. Effective isolation among different virtual machines running on the same host is promised, as well as isolation from the operating system that might be present on the host itself. These barriers are necessary, as cloud computing may create a situation where both provider and customer do not trust each other: The provider wants to keep full control over their expensive server hardware and the customer may want to process sensitive data inside their virtual machine that neither the provider nor other customers are allowed to see. As such, there are several attacker models to be considered in this context, both customers and hosting providers wanting to take control over other virtual machines or the physical server itself. In this paper, we consider attacks for each of the attacker models, as well as possible mitigations. In the end, we will find that while preventing VM escapes only really depends on having secure hypervisor implementations, efforts to protect the VM from the host itself are still rather flawed.
Keywords: Virtualization, VM Escape, Hypervisor, AMD SEV, Intel SGX
1 Introduction
The vast majority of today’s companies use the cloud. As found by the 2018 IDG Cloud Computing Survey, 73% of businesses use the cloud to outsource parts of their IT infrastructure or to deliver at least one application to customers [5]. While the reasons to do so may be manifold, e.g. reducing cost or the amount of needed maintenance staff, there is one aspect that unites nearly all customers of cloud hosting providers: They do not run their software on a dedicated physical server that is provided exclusively to them. Instead, they manage virtual machines (VMs), either single ones or whole automated clusters, where VMs of different corporations may reside on the same physical hosting server. This technique is used by the server provider so that their resource usage can be optimized to provide their hosting services to as many customers as possible.
The concept of hardware virtualization serves as an abstraction layer from physical computer hardware. It behaves as if a single computer was actually a set of several machines, where each has their own CPU, memory and set of peripherals. Like this, each customer can install the operating system of their choice, including any software they want to run, regardless of what else is actually running on the physical server. The customer only sees their own machine and they can do whatever they want with it.
This flexibility is of course one of the big reasons why cloud computing is so compelling for customers: Instead of having to buy an expensive server and hire staff to take care of it, they can “rent” computing power for whatever application they want, dynamically adapting the number of VMs to their actual current need.
Unfortunately, as with any computer system, there are security issues that need to be addressed when using virtualization technologies: Can the cloud computing customer process sensitive information in their VM without the provider or anyone else gaining access to it? Can the hosting provider be sure that neighboring VMs are strictly isolated from each other? Is it ensured that neither a malicious provider can manipulate VM execution nor a malicious VM can compromise the whole physical server?
In the following sections, we will first take a look at basic principles of virtualization, followed by a discussion of different attacker models, answering the questions mentioned above. For each attacker model, a specific attack will be presented, as well as how they could be mitigated.
2 Virtualization Techniques
Running multiple virtual machines on a single physical computer creates a scenario where these VMs compete against each other for the available resources. Thus, analogous to the scheduler in a multiprocessing environment, we need an authoritative entity that manages hardware access in a way that each VM gets the impression of being the only machine on the system. In the area of virtualization, this entity is called the Virtual Machine Monitor (VMM), also known as the hypervisor.
The hypervisor’s task is to emulate a separate copy of all relevant resources of the physical machine, like CPU, memory or peripherals, for each of the virtual machines it manages. In order to achieve this in an efficient way, the VMM needs to execute as much of each VM’s code as possible directly on the hardware, but some critical instructions have to be treated differently. Memory accesses for example have to be steered away from other machines’ data and privileged actions like disabling interrupts must not impact neighboring VMs or the hypervisor itself.
Tanenbaum and Bos distinguish two types of hypervisors, based on their position in the typical operating system stack, as shown in Fig. 1. Type I hypervisors, commonly referred to as “bare-metal hypervisors” operate directly on the physical hardware, while their type II counterpart is a program running inside a host operating system [12]. Both techniques have their own advantages and disadvantages, as we will see in the following sections.
Abbildung in dieser Leseprobe nicht enthalten
Fig. 1 : Location of different hypervisor types in the operating system stack
2.1 Bare-Metal Virtualization (Type I)
As their name suggests, “bare-metal” hypervisors run directly on the physical hardware. Like this, they take the place of a traditional operating system, directly managing the CPU, memory and other resources. This brings the advantage that virtual machines can be executed with minimal performance loss, as there is no other system underneath the hypervisor that could limit the available computing resources. Another benefit of the VMM being the most privileged piece of software on the system is that it does not rely on its host being secure or trustworthy. The only attack vector here is the hypervisor itself, which in turn is a very small program compared to typical consumer operating systems. Thus the attack surface and amount of bugs to be expected is smaller.
This virtualization concept is targeted towards enterprise settings, where virtual machines run on servers inside data centers. Here, there is no need for a host operating system, but the final goal is to run as many VMs as possible, as efficiently as possible. Having to use a special management interface in order to control the installed virtual machines is not an issue here, as the end-user normally only cares about their VM instances. All hypervisor-related management tasks are carried out by designated staff.
2.2 Hosted Virtualization (Type II)
Type II hypervisors on the other hand do not run in the highest CPU privilege level but rather sit on top of a host OS. Of course this makes them vulnerable to attacks coming from the host and also degrades virtual machine performance, as the host OS also requires a certain share of the hardware resources. But an advantage of this type of VM management is that it is better suited for end users in need of VMs: Usually, the user has one main operating system installed on their machine, and for some special tasks, they are in need of a VM. Use cases for this include tasks that can only be carried out on an OS the user does not want to use as their primary one (e.g. Linux users required to test software on Windows or malware researchers trying to debug Windows binaries), testing a new operating system before deciding to permanently install it and many more. In this scenario, the user may not want to reboot to an OS stored on another hard disk partition, as they still need access to features of their host OS in the meantime. Malware analysts, for example, may have reverse engineering tools installed on their host, that need to be interacted with during debugging sessions.
When using type II hypervisors, the virtualization software usually also makes use of so-called para-virtualization techniques: Here, the guest OS contains modified driver software which is aware of the ongoing virtualization. Like this, the virtual machine explicitly communicates with the hypervisor through hypercalls, and may thus be able to create a bridge between the host OS and itself. Use cases are for example file sharing between both systems and shared clipboards to provide a more seamless user experience. Para-virtualization is also available with type I hypervisors, although here it is not used to provide the aforementioned improvements to the general user experience, due to the lack of a host OS to bridge to. Instead, para-virtualization is used to further increase the VM performance by reducing the amount of sensitive instructions that the hypervisor would normally need to trap and handle separately. In order to achieve this, these sensitive instructions are replaced by dedicated hypercalls.
3 Attacker Models
Now that we have seen what a hypervisor does and what different concepts for virtualization exist, we can go on to take a look at different ways how attackers might want to circumvent security measures that are put in place for virtual machine isolation.
In the following sections, several attacker models are presented, detailing their location in the virtualization stack and what their goals are. A sample attack is presented for each of these models, as well as possible mitigation strategies.
3.1 Guest VM User
The first scenario, shown in Fig. 2, is the most widespread type of potential attacker: A user inside a virtual machine, trying to break out of it. Malicious VM users probably are the kind of threat that virtualization platforms need to protect against the most, as this is the most exposed contact point.
Hosting providers often don’t directly give clients a server in their data center, but rather they give them the ability to spin up one or more virtual machines on their infrastructure. Clients therefore can have full control over everything that happens on their rented machine, without the hosting provider needing to give out privileged access over their physical servers. This can be considered a win-win situation for both, as the client can install any software stack they like without having to ask the provider to do so, and the provider themselves have the guarantee that they remain the only one with full administrative access to their server, with the client’s virtual machines only acting as guests.
Abbildung in dieser Leseprobe nicht enthalten
Fig. 2 : Attacker model 1: Malicious guest VM user
At least this is what the provider hopes for, relying on the effectiveness of isolation measures taken by the hypervisor running on the physical hardware. Malicious clients may aim to break out of this isolation and either take over the host server itself or compromise VMs of other clients running on the same machine. This kind of attacker is expected to have full superuser access to the OS of his own virtual machine, but neither physical nor remote access to administrative interfaces provided by the hypervisor that are to be used by the hosting provider.
One attack vector such an actor might want to exploit is using side-channels to exfiltrate sensitive data located anywhere in the RAM, thus also data from other VMs that are stored in locations where the hypervisor would normally not allow access to. Very prominent practical examples for such theoretical sidechannels are the Spectre and Meltdown vulnerabilities, found in 2018. These affected modern CPUs directly on the hardware level, thus this data leakage of any RAM contents could be carried out without any way of being prevented by the hypervisor [7, 8]. Even worse are side-channels that can be used to leak data across physical CPU cores, for example the CROSSTalk attack presented by Ragab et al. in June 2020 [11].
But while data exfiltration might be one goal of a malicious VM user, complete executable control over the hypervisor itself is even more dangerous. If this is achieved, the attacker can not only control all virtual machines on the host, but in case of a type I hypervisor, the administration interfaces provided to the legitimate owner of the server can be shut down as well, effectively making the attacker the only true owner of the whole machine. This is why we will now look at such an attack in more detail.
Attack Example: Guest to Hypervisor Escape In 2015, Crowdstrike researcher Jason Geffner discovered a vulnerability in a piece of code that was integrated in several open source hypervisors, called VENOM and listed as CVE-2015-3456. Successful exploitation of this vulnerability could lead to arbitrary code execution with the privilege level of the underlying hypervisor. Both type I hypervisors (e.g. Xen) and type II (primarily QEMU, but also KVM, VirtualBox and others) have been affected. [2]
The vulnerable code is located in QEMU's virtual floppy disk controller. This controller receives commands from the guest operating system, e.g. to perform seeking, reading or writing operations on a virtual floppy disk. For these commands, a fixed-size buffer is used for command ID and parameter storage. When receiving a command, the controller checks how much data is expected to be sent by the virtual machine. Once all data is available, the command is executed and the counter that keeps track of the current position inside the buffer is reset. Unfortunately, an immediate reset is only performed for all but two commands, which wait a given time before clearing the counter. This provides the attacker with a small time window during which they can send more data to the controller than expected, resulting in an overflow of the buffer. According to Crowdstrike, this overflow could then be used to inject arbitrary code to be executed with hypervisor privileges. [3]
Mitigation In order to mitigate VENOM, it was only necessary to force the position counter to not exceed the size of the buffer. Generally speaking, the only way of preventing an escape from VM level to hypervisor privileges is to continuously audit the hypervisor software and disable unneeded components, like virtual peripherals, in order to further decrease the attack surface. Unfortunately, the VENOM vulnerability in particular could not be avoided by disabling the virtual floppy disc controller in Xen and QEMU, as the vulnerable code could still be triggered through other ways in this case. [2]
Spectre and Meltdown are much harder to prevent, as their cause is inherent in current processor design. While newer CPUs have been hardened against those attacks, speculative execution as the root cause for this class of vulnerabilities is still important for high performance, so further variants of these side-channel attacks may again circumvent the new mitigations. Purely software-based fixing approaches on the other hand lead to additional performance reductions, which makes defense against such attacks in general quite difficult.
3.2 Host OS User
A different kind of malicious actor is a user on the host system that wants to access data from running VMs and potentially also manipulate the machine, as shown in Fig. 3.
Abbildung in dieser Leseprobe nicht enthalten
Fig. 3: Attacker model 2: Malicious user on the host system
One example where this scenario might appear is the following: A small hosting provider runs type II virtual machines for his users, giving them access to their VM via the network. (Large-scale providers would use dedicated servers for this, running just a hypervisor instead of a full host OS, but we will get to this in section 3.3). One might think that this way of hosting is not really widespread, but e.g. in academic environments, lab course supervisors might not get an own dedicated server for their course but only a virtual machine themselves. They are given a subset of a single server's resources and can then distribute the number of virtual CPU cores onto their pupils' virtual machines. Such a situation is called nested virtualization and typically requires the supervisor to run a type II hypervisor on top of their VM's host OS.
When VM hosting is done this way, the hypervisor is just another application running alongside normal OS processes. Thus, the same security boundaries exist as with normal software: A user on the host system can only interact with their own processes and files, or those where access is allowed explicitly. So in our multi-user hosting environment, each user can only access their own VMs, including any files required for their operation. Machines operated by other users are not accessible.
Attack Example: Accessing VM Data as a Host OS User In the following discussion, we will use this previously mentioned lab course environment as an example. Here, each student is assumed to get access to an own account on the supervisor's VM, where they can then manage and run their own virtual machine. The supervisor has access to all files created by the students, as they have full administrative access to their own machine.
A typical setup for type II virtualization, e.g. with QEMU, stores the contents of a VM's virtual hard drive in a file on the host system. While unauthorized access by other students is prevented securely by file system permissions, if the supervisor would like to read or even manipulate data located on the students' hard drives, they can do so without any problem. This is due to the fact that once a user has full root access to the host machine, no file system restrictions apply for them.
What makes this situation even worse for the affected users, is that not only the virtual hard disk of a VM is saved to the host file system, but also state information concerning the machine's RAM and CPU register contents might end up there, in case a so-called VM snapshot is taken. Snapshot functionality is often used to be able to pause a VM and resume it at a later point in time, without losing runtime data. Now if the attacker has access to the file containing snapshot data, they can manipulate the machine in any way they like, even implanting pieces of code that will be executed once the machine is resumed, resulting in complete and hard to detect control over the guest. Such a RAM manipulation can also be carried out in a more direct way: Users with root privileges are allowed to read and write to the RAM of any arbitrary process running on the host. As such, a malicious host administrator can also manipulate running VMs, not just suspended ones.
Most type II hypervisors also offer several features to integrate the guest system more into the host OS, e.g. with clipboard- or folder-sharing. This reduces the usually rather strict separation between guest and host, in order to allow data flow between the two systems, making some tasks more comfortable for the user. But with more comfort often comes a greater security risk, which is also the case with these data-sharing features: When clipboard synchronisation is enabled, a malicious actor on the host system may be able to read sensitive data from the VM's clipboard without the user noticing, or even manipulate the clipboard contents in order to inject malicious data into the guest machine. Sharing parts of the host file system with the guest poses a similar attack vector, providing a way of manipulating data that is later on used inside the VM.
Mitigation When relying on a type II hypervisor, mitigating attacks coming from a host administrator is a difficult task, given the situation that users with root privileges have at least the same privilege level as the hypervisor itself, if not more. As such, no security mechanism of the host system can be trusted to suffice.
One option to harden a virtual machine is to use disk encryption for the virtual hard drive. This protects against attackers who have access to its backing file on the host file system. Unfortunately, this also does not fully protect against attackers with root privileges: As the VM needs to be able to decrypt the hard drive itself, it needs to store the decryption key somewhere in memory. As a root-level adversary has access to the memory contents of any process, they can also find this decryption key and circumvent the disk encryption.
The attack vectors provided by shared clipboard and folders are relatively easy to mitigate: While potentially making some tasks less convenient for the user, disabling any hypervisor features that poke holes into the usual separation between guest and host is an important step towards making a VM less vulnerable against host OS users.
3.3 Hypervisor
The third and arguably most dangerous type of attacker (now in a type I virtualization context) has hypervisor-level privileges, shown in Fig. 4.
The hypervisor’s role to act as the interface between VM and the hardware itself, thus it inherently has access to the complete state information of a virtual machine: Register values, page tables that map a guest’s memory address to the actual physical address and so on. Data exfiltration attacks, for example, are rather trivial at this privilege level, as the attacker gets direct readable and writable access to any of the guest’s memory pages and can even alter code execution to their liking. This cannot be noticed by the VM itself.
Now the question might arise as to how relevant any of this is, as having a malicious hypervisor may sound like an exotic situation, in which case not a single rest of security can be guaranteed for the guest anyway. But actually this attacker model is not as unrealistic as it seems: Especially since the European General Data Protection Regulation was put into place, companies that lose sensitive data about their customers face critical fines and reputation damages. Thus, they need to ensure that each system used to handle these kinds of data is secured against data exfiltration. In the case of outsourced servers, the hosting provider is another instance that needs to be trusted with this data. Depending on the physical location of this provider, the local law enforcement agencies might also be a potential party that wants to get access to any sensitive information stored and processed by VMs the provider manages. All things considered, anybody who needs to process confidential data inside their VMs is best advised to trust the hosting provider and their hypervisor as little as possible.
[...]
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.