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.
Table of Contents
1 Introduction
2 Virtualization Techniques
2.1 Bare-Metal Virtualization (Type I)
2.2 Hosted Virtualization (Type II)
3 Attacker Models
3.1 Guest VM User
3.2 Host OS User
3.3 Hypervisor
4 Conclusion
Objectives & Research Topics
The primary objective of this paper is to examine security challenges inherent in hardware virtualization, specifically focusing on the isolation barriers between virtual machines, the host operating system, and the hypervisor. It investigates various attacker models to determine how security measures can be circumvented and evaluates potential mitigation strategies.
- Analysis of virtualization concepts (Type I and Type II hypervisors).
- Evaluation of threats posed by malicious guest VM users.
- Examination of security risks for users on the host operating system.
- Assessment of hypervisor-level attacks and vulnerabilities in hardware-based protection (e.g., AMD SEV, Intel SGX).
- Review of mitigation techniques and the difficulty of securing encrypted memory.
Excerpt from the Book
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]
Summary of Chapters
1 Introduction: This chapter introduces the prevalence of cloud computing and the foundational role of hardware virtualization in resource abstraction and multi-tenancy.
2 Virtualization Techniques: This section details the operational differences between Type I (bare-metal) and Type II (hosted) hypervisors, highlighting their respective impacts on performance and privilege levels.
3 Attacker Models: This chapter categorizes potential threats into three primary models—malicious VM users, malicious host OS users, and malicious hypervisors—and discusses relevant attack examples and mitigation challenges for each.
4 Conclusion: The concluding chapter summarizes that while basic VM isolation is effective, protecting against malicious hypervisors remains a significant, unresolved security challenge.
Keywords
Virtualization, VM Escape, Hypervisor, AMD SEV, Intel SGX, Cloud Computing, Side-channel Attacks, Spectre, Meltdown, Data Exfiltration, Memory Encryption, CROSSTalk, SEVered, Security Vulnerabilities, Infrastructure Isolation.
Frequently Asked Questions
What is the primary scope of this paper?
The paper examines security issues within hardware virtualization, focusing on how different attackers—ranging from guest users to the hypervisor level—can compromise virtual machine isolation.
What are the central themes discussed?
The core themes include the architecture of hypervisors, the threat models for various system users, and the limitations of modern security technologies like AMD SEV and Intel SGX in preventing unauthorized data access.
What is the ultimate goal of the research?
The research aims to determine the effectiveness of current isolation mechanisms and identify why protecting virtual machines from a compromised or malicious hypervisor remains a difficult, yet critical, challenge.
Which methodologies are utilized for the analysis?
The author analyzes established virtualization models (Type I and Type II) and evaluates specific real-world attack scenarios (such as VENOM, Spectre, and SEVered) to demonstrate security flaws.
What topics are covered in the main body?
The main body systematically explores virtualization techniques, delineates distinct attacker profiles, discusses specific exploits targeting hardware and hypervisor memory, and proposes or critiques various mitigation strategies.
Which keywords best characterize this work?
The work is characterized by terms such as Virtualization, VM Escape, Hypervisor, Memory Encryption, and side-channel vulnerabilities like Spectre, Meltdown, and SEVered.
How does the VENOM vulnerability demonstrate a threat?
The VENOM vulnerability highlights how a flaw in an emulated device driver, specifically a virtual floppy disk controller, can allow an attacker to escape a VM and execute code with hypervisor privileges.
Why is defending against a malicious hypervisor so difficult?
Defending against a malicious hypervisor is difficult because the hypervisor inherently holds the highest privilege level in the system, managing all memory access, register states, and hardware resources, making it nearly impossible for the VM to detect interference.
What is the significance of the SEVered attack?
SEVered is significant because it demonstrates that even with hardware-based memory encryption (like AMD SEV), a malicious hypervisor can still exfiltrate data by manipulating memory page mappings, exposing a design flaw in early encryption implementations.
- Quote paper
- Samuel Hopstock (Author), 2020, Security Issues in Hardware Virtualization, Munich, GRIN Verlag, https://www.grin.com/document/933815
