Virtualization from an Attacker Point-Of-View

Virtualization from an Attacker Point-Of-View

Speakers: Corentin Bayet (Synacktiv); Thomas Bouzerar (Synacktiv)

Conference: GreHack

YouTube: https://www.youtube.com/watch?v=He_JPg6ldgM

Overview

This talk, "Virtualization from an Attacker Point-Of-View," delivered by Corentin Bayet of Synacktiv at GreHack, delves into the intricate world of hypervisors and their associated attack surfaces. While Corentin was initially slated to present alongside his colleague Thomas Bouzerar, he commendably handled the presentation solo due to Thomas's last-minute absence. The core objective of the presentation is to illuminate how attackers can exploit vulnerabilities within virtualization environments to achieve a VM escape, gaining unauthorized access from a guest virtual machine to the underlying host or hypervisor.

The talk is crucial for security professionals, developers, and researchers alike, as it demystifies the complex mechanisms of virtualization and highlights the critical security implications. In an era dominated by cloud computing and virtualized infrastructures, understanding these attack vectors is paramount for maintaining data isolation and system integrity. Bayet reviews fundamental virtualization concepts, dissects various attack surfaces, and provides concrete examples of real-world vulnerabilities discovered in prominent hypervisors, underscoring the constant battle between performance optimization and robust security in these low-level systems.

Background

▶ Watch: Talk introduction and virtualization definitions (0:00)

Virtualization is the technology that enables the illusion of multiple independent computers running concurrently on a single physical hardware platform. The software responsible for orchestrating this feat is known as a hypervisor. Common examples include Microsoft Hyper-V, VMware ESXi, Oracle VirtualBox, and VMware Workstation. A critical component within the hypervisor is the Virtual Machine Monitor (VMM), which manages the CPU, memory, and other resources essential for a virtual machine to operate. The operating system running inside the virtualized environment is referred to as the guest.

The hypervisor's fundamental responsibilities include virtualizing the CPU and memory, managing platform components like timers and interrupts, and emulating input/output (I/O) devices such as network cards, disks, and graphics adapters. These tasks must adhere to three core criteria:

1. Fidelity: Programs should run identically in a virtual environment as they would on physical hardware.
2. Performance: The majority of guest instructions should execute directly on the hardware without frequent VMM intervention.
3. Safety: Resources between VMs must remain isolated, and, critically, the host must be isolated from the guest. The talk primarily focuses on this safety aspect from an attacker's perspective.

The attacker's ultimate goal in this context is a VM escape (VME), which involves achieving code execution on the hypervisor or host from within a guest virtual machine. This primitive is extremely powerful, with severe implications for cloud computing, hosting providers, and malware analysis environments, where compromised isolation could lead to widespread data breaches or malware escaping its sandbox.

Historically, full virtualization with binary translation (pioneered by VMware in the 1990s) allowed unprivileged guest instructions to execute directly on the CPU, while privileged instructions (e.g., I/O operations, CPU flag changes) were translated into traps, handled by the VMM, and then execution returned to the guest. This approach offered transparency and portability but suffered from significant VMM complexity and CPU overhead.

Modern hypervisors largely rely on hardware-assisted virtualization, enabled by CPU features like Intel VT-x and AMD AMD-V. These technologies introduce a new CPU privilege level that is aware of virtualization, allowing most instructions to execute natively. The CPU itself handles privileged operations, triggering a VM exit to the hypervisor when VMM intervention is required, and returning control to the guest via a VM enter operation. This significantly improves performance compared to binary translation.

Finally, paravirtualization offers a different approach where the guest OS is modified to explicitly cooperate with the hypervisor. This involves using hypercalls—direct calls from the guest to the VMM—for privileged operations, leading to simpler VMMs and better performance. However, it sacrifices transparency and portability, as the guest must be specifically adapted for the hypervisor. Contemporary hypervisors often employ a hybrid approach, leveraging hardware assistance for CPU/memory (e.g., SLAT for memory management) and paravirtualization for performance-critical I/O devices. An important note for malware researchers is that paravirtualization is typically avoided when analyzing malware to prevent the malware from detecting its virtualized environment.

Regarding architecture, hypervisors are broadly categorized into two types:

1. Bare-metal hypervisors (Type 1): These run directly on the hardware, such as Xen or VMware ESXi.
2. Host hypervisors (Type 2): These run as an application within a conventional operating system, like VirtualBox or VMware Workstation.

However, this distinction has blurred over time, as many Type 1 hypervisors now include a base OS (e.g., Windows for Hyper-V, Linux for VMware ESXi) to manage user applications. An example is Microsoft Hyper-V, which acts as a bare-metal hypervisor. When Windows 11 is installed, Hyper-V is installed first, and Windows itself runs within a privileged root partition. Other less privileged guest partitions can then run, often utilizing a VM bus for paravirtualized, high-performance communication.

Key Findings

▶ Watch: Full, hardware-assisted, and paravirtualization techniques (4:10)

The talk identifies a broad and complex array of attack surfaces exposed by hypervisors, ranging from core CPU and memory management units to various virtualized devices and guest interaction tools. Corentin Bayet categorizes these surfaces and highlights where attackers are most likely to find exploitable vulnerabilities.

The primary attack surfaces discussed include:

• Memory Management Unit (MMU): The hypervisor's role in managing guest memory and ensuring isolation, often leveraging hardware features like SLAT (Second Level Address Translation) to map guest virtual addresses to host physical addresses efficiently.
• Nested Virtualization: The ability to run a hypervisor inside another virtual machine. This introduces significant complexity, as the outer hypervisor must emulate hardware virtualization features (like VT-x/AMD-V) for the inner hypervisor, making it a rich target for bugs. Key data structures like Intel's VMCS and AMD's VMCB are central to configuring the CPU for virtualization and thus become critical attack points.
• I/O Buses (PCI, USB): These interfaces allow guests to access emulated devices or, in some configurations, directly access physical hardware via pass-through. Emulating complex protocols like USB or PCI presents a wide attack surface for protocol-level bugs or vulnerabilities in the emulated devices themselves.
• Paravirtualization Interfaces: Hypercalls and specific interfaces (like Hyper-V's VM bus) designed for performance can also introduce vulnerabilities if not implemented securely.
• Graphics Acceleration: Modern hypervisors often provide shared GPU access, involving complex 3D graphics acceleration, shaders, and bitmaps. These interfaces, while not always enabled by default, have historically been a source of significant vulnerabilities (e.g., in VMware's SVGA, VirtualBox's VMSVGA).
• Guest Additions: Tools like copy-paste, drag-and-drop, and shared folders, typically installed on host hypervisors (Type 2) for user convenience, were historically a popular attack vector due to their dangerous features and relative simplicity. While less prevalent as a primary attack surface today, they still represent a potential entry point.

Bayet concludes that while complex components like the MMU, CPU isolation, and nested virtualization offer extremely powerful exploitation primitives (e.g., full host control), their inherent complexity makes finding and exploiting bugs in them highly time-consuming and challenging. Consequently, the majority of publicly disclosed vulnerabilities are found in emulated or paravirtualized devices. These components often suffer from "classic C-style bugs" such as buffer overflows, integer overflows, and use-after-free vulnerabilities. Attackers can often exploit these without needing a deep understanding of the entire virtualization stack, making them more accessible targets. The talk provides several examples illustrating this trend.

Technical Deep Dive

▶ Watch: Recursive MMIO callback vulnerability pattern (18:50)

Corentin Bayet walks through several real-world vulnerabilities, illustrating the diverse nature of bugs found in hypervisors, particularly in emulated and paravirtualized devices.

1. MMIO Recursive Pattern (QEMU USB 2.0 Emulation)

The first pattern discussed involves Memory Mapped I/O (MMIO), a mechanism where a specific memory range is used by the guest to communicate with an emulated device. When the guest reads from or writes to this range, the host traps and executes a callback function. Typically, data transfer occurs via Direct Memory Access (DMA), where the guest provides a DMA range address as an argument, and the host reads/writes to this shared memory.

The vulnerability pattern emerges when a guest provides an MMIO range itself as an argument to an MMIO operation, instead of a DMA range. This can lead to a recursive MMIO call:

• Guest writes to MMIO range A.
• Host executes callback for A.
• Guest's argument to A's callback is MMIO range B.
• Host writes to MMIO range B.
• This triggers another callback for B.

This recursive behavior, if not properly handled, can lead to unexpected states, such as a device structure being freed during the nested callback, resulting in a use-after-free vulnerability when control returns to the first handler.

This exact pattern was found in QEMU's USB 2.0 emulation (specifically, the EHC controller). An attacker could set a USB transfer buffer to an MMIO range. By carefully timing packet transfers, an error in mapping the second packet would trigger an error handler. This handler, attempting to write back to the MMIO range (which was the attacker-controlled buffer), would trigger a recursive callback. If the attacker manipulates this to call the EHC reset function, the entire device state could be freed, leading to a use-after-free in the original handler. This complex pattern was detailed in the paper "Mat Cattrat."

1. VirtualBox TPM Stack Buffer Overflow

Thomas Bouzerar (the speaker's colleague) discovered a straightforward stack buffer overflow in the emulation of the Trusted Platform Module (TPM) device on VirtualBox. With Windows 11 requiring TPM, this is a relatively new and critical code path. The vulnerability was found in a function responsible for transferring data between the TPM device and the guest. This function used memcpy to copy data from the guest without adequately checking the size of the destination buffer against the size of the copied data. This allowed a malicious guest to write beyond the bounds of a stack-allocated buffer, corrupting the stack and potentially overwriting the return address. This is a classic vulnerability, highlighting that even in complex virtualization environments, fundamental C-style memory safety issues persist.

1. VirtualBox DMA Uninitialized Data Leak

To fully exploit the TPM stack buffer overflow, an attacker typically needs to bypass ASLR (Address Space Layout Randomization) and potentially leak stack cookies. Another bug found in VirtualBox, affecting the DMA part and an emulated device, provided this crucial information. This vulnerability was located in a low-level API function called PGM Fe read, which is invoked when an emulated device needs to read memory from the guest using DMA.

The function iterates through guest memory page by page, copying data to a destination buffer. However, if it encounters an MMIO range during this process, it calls an MMIO callback. The critical flaw is that if this MMIO callback fails, the PGM Fe read function will terminate prematurely, but it will leave the last page of the destination buffer uninitialized. Many devices use this fundamental DMA function. If such a device then uses this uninitialized last page and writes its content back to guest memory, the guest can read arbitrary uninitialized heap or stack data from the host. This effectively bypasses ASLR and leaks stack cookies, making the stack buffer overflow exploitable. This bug chain (TPM stack overflow + DMA uninitialized data leak) was successfully exploited by Thomas Bouzerar at Pwn2Own earlier this year to achieve a full VM escape from VirtualBox.

1. QEMU Nested Virtualization Double-Fetch

Moving to more complex attack surfaces, a double-fetch vulnerability was discovered in QEMU's handling of nested virtualization. When a hypervisor virtualizes another hypervisor, it needs to configure the CPU using structures like AMD's VMCB. QEMU would fetch the VMCB configuration from the guest twice: once to validate its values and a second time to actually apply the configuration to the hypervisor. This creates a race condition where a malicious guest can modify the VMCB data between the two fetches, bypassing the initial security checks. This specific vulnerability gave the guest access to the host's MSR (Model-Specific Register) register, providing control over memory segmentation. While non-trivial to exploit, this bug, found and exploited by Felix Wilhelm from Google Project Zero, demonstrates how subtle timing issues in complex virtualization logic can lead to powerful primitives. It notably affected only AMD CPUs due to its specific interaction with the VMCB.

1. Hardware/CPU Bugs (Meltdown, Spectre, L1 Terminal Fault)

Finally, the talk touches upon vulnerabilities residing directly in the underlying hardware, specifically CPU bugs. These are not hypervisor software bugs but rather flaws in the CPU's design or implementation that can be exploited from a guest to break isolation. Well-known examples include Meltdown and Spectre, which allowed side-channel attacks to leak sensitive data across privilege boundaries, and L1 Terminal Fault (L1TF), which enabled data leakage from the L1 cache. The root causes of these bugs often lie in performance-optimizing features (e.g., speculative execution, caching mechanisms) that introduce unintended side effects or race conditions. Fixing these bugs typically involves performance penalties. As CPU vendors continuously innovate for speed, new performance features are likely to introduce new classes of hardware vulnerabilities, making this a perpetually interesting, albeit highly complex, attack surface.

Demo / Proof of Concept

▶ Watch: VirtualBox TPM stack overflow and DMA leak exploit (22:15)

While the talk thoroughly details several vulnerabilities and their exploitation patterns, Corentin Bayet explicitly states early in the presentation that he "won't go too deep into the details of the exploitation of the bugs because it's not the point of the talk." The focus is on the attack surfaces and the types of vulnerabilities found, rather than a live demonstration or step-by-step proof of concept within this specific presentation.

However, it's worth noting that one of the discussed bug chains—the VirtualBox TPM stack buffer overflow combined with the DMA uninitialized data leak—was indeed leveraged by Thomas Bouzerar to successfully achieve a VM escape at Pwn2Own earlier in the year. This demonstrates that these vulnerabilities are not merely theoretical but have been proven to lead to full exploits in a competitive, real-world setting. The technical details provided in the talk serve as a conceptual walkthrough of how such exploits are constructed, rather than a live demonstration.

Defensive Implications

▶ Watch: Q&A: Debugging bare-metal hypervisors (30:50)

Understanding the attack surfaces and vulnerabilities discussed in this talk provides crucial insights for defenders aiming to secure virtualized environments. Several key defensive strategies emerge:

1. Prioritize Patching: The recurrence of "classic C-style bugs" in emulated and paravirtualized devices underscores the paramount importance of keeping hypervisors and their components fully patched. Many exploits, including those demonstrated at Pwn2Own, target recently discovered vulnerabilities. Timely application of security updates is the first and most critical line of defense.
2. Careful Configuration of Emulated Devices: Many vulnerabilities reside in emulated I/O devices (USB, network cards, TPM, graphics). Defenders should minimize the attack surface by only enabling necessary emulated devices for guest VMs. For example, if a VM doesn't require USB 2.0 or a TPM, these features should be disabled to remove potential entry points.
3. Restrict Paravirtualization Features: While paravirtualization offers performance benefits, its interfaces can introduce vulnerabilities. In security-sensitive environments (e.g., malware analysis), transparent virtualization might be preferred over paravirtualization to prevent guest awareness and reduce the attack surface.
4. Limit Guest Additions: Guest additions, while convenient, expose dangerous features like shared folders and clipboard sharing. For high-security VMs, these should be disabled or not installed at all, as they have historically been a source of VM escapes.
5. Be Wary of Nested Virtualization: Nested virtualization significantly increases the complexity of the hypervisor's attack surface due to the need to emulate hardware virtualization features. Unless absolutely necessary, nested virtualization should be avoided in production environments, or its use should be heavily scrutinized and secured.
6. Monitor for Hardware Vulnerabilities: CPU-level bugs (Meltdown, Spectre, L1TF) are a persistent threat. Defenders must stay informed about new hardware vulnerabilities and apply vendor-provided microcode updates and patches, even if they come with performance trade-offs.
7. Implement Robust Memory Protections: The VirtualBox DMA uninitialized data leak highlights the need for strong memory initialization practices. Developers of hypervisors should employ secure coding practices, including explicit memory initialization and rigorous bounds checking for all memory operations, especially when handling data transfer between host and guest.
8. Security Audits and Fuzzing: Given the complexity, regular security audits, penetration testing, and extensive fuzzing of hypervisor components, particularly emulated devices and paravirtualization interfaces, are essential to proactively identify and mitigate vulnerabilities before they are exploited in the wild.

By adopting these defensive postures, organizations can significantly reduce their exposure to VM escape attacks and enhance the overall security posture of their virtualized infrastructure.

Key Takeaways

• VM Escape is a Critical Threat: Gaining code execution on the hypervisor/host from a guest VM is a highly powerful primitive with severe implications for cloud security, data isolation, and malware analysis.
• Emulated Devices Are Primary Targets: The majority of disclosed hypervisor vulnerabilities are found in emulated or paravirtualized I/O devices (e.g., USB, TPM, graphics) due to their complexity and susceptibility to "classic C-style bugs" like buffer overflows and use-after-free.
• Complexity Breeds Vulnerabilities: Core hypervisor components (MMU, CPU virtualization, nested virtualization) are extremely complex, making them hard to secure and hard to attack. However, vulnerabilities here can yield immediate host control.
• Hardware Bugs Cannot Be Ignored: CPU-level vulnerabilities (e.g., Meltdown, Spectre) can break VM isolation, often stemming from performance-enhancing features. Staying updated with microcode and OS patches is crucial.
• Defensive Configuration is Key: Minimizing the attack surface by disabling unnecessary emulated devices, avoiding guest additions in high-security contexts, and carefully considering nested virtualization can significantly enhance security.
• Bug Chaining is Common: Achieving a full VM escape often involves chaining multiple vulnerabilities, such as a memory leak to bypass ASLR combined with a memory corruption bug for code execution.

About the Speaker(s)

Corentin Bayet is a member of the reverse engineering team at Synacktiv, a company known for its low-level research, reverse engineering, and vulnerability research. He specializes in hypervisor security and has previously presented vulnerabilities in hypervisors at conferences like Pwn2Own. His expertise lies in analyzing and reversing complex software, especially in the virtualization domain, and he enjoys the intricate challenges of low-level vulnerability research and exploit development.

Thomas Bouzerar, also part of Synacktiv's reverse engineering team, shares Corentin's focus on low-level security research. He is recognized for his contributions to hypervisor vulnerability research, including successfully demonstrating VM escapes at prestigious events like Pwn2Own. Although he was unable to present at GreHack, his work, particularly the VirtualBox TPM and DMA vulnerability chain, was a significant part of the talk's technical deep dive.