Escaping From VMware Workstation Through The Disk Controller

Escaping From VMware Workstation Through The Disk Controller

Speakers: Wenxu Yin, Vulnerability Researcher, Qihoo 360 Alpha Lab

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=_PfuJN-I8-8

Overview

In this compelling presentation at HITB Phuket, Wenxu Yin from Qihoo 360 Alpha Lab detailed a critical VMware Workstation vulnerability, CVE-2023-20872, that allows a malicious guest virtual machine to execute arbitrary code on the host operating system. The talk, titled "Escaping From VMware Workstation Through The Disk Controller," provided a deep dive into the root cause of an out-of-bounds read/write flaw within VMware's emulation of the LSI Logic 53c1030 SCSI disk controller. This vulnerability highlights the persistent challenges in securing complex emulated hardware interfaces within hypervisors.

Yin's research unveils how a subtle oversight in handling modern SCSI (Small Computer System Interface) specifications, specifically the allowance for variable-length CDBs (Command Descriptor Blocks), broke long-standing assumptions in VMware's code. By meticulously crafting a malformed CDB, a guest VM can trigger a heap corruption, leading to powerful exploit primitives like arbitrary memory read, write, and ultimately, arbitrary code execution. The implications are severe, as a successful exploit enables a full VM escape, granting an attacker control over the underlying host system, bypassing the hypervisor's security boundary.

This talk is crucial for security researchers, hypervisor developers, and system administrators. It not only exposes a significant vulnerability but also offers valuable insights into the methodologies for bug hunting in hypervisors, emphasizing the importance of understanding hardware specifications and driver implementations. Yin's demonstration of achieving code execution on both Linux and Windows hosts underscores the broad impact of this class of vulnerabilities and the sophisticated techniques required to exploit and mitigate them.

Background

▶ Watch: Introduction and Talk Agenda (0:00)

The core of this vulnerability lies within the intricate world of emulated hardware, specifically disk controllers, which bridge the gap between a computer's main system and its storage devices. Historically, three main standards have dominated this space: IDE (Integrated Drive Electronics), SATA (Serial ATA), and SCSI (Small Computer System Interface). In virtualized environments like VMware Workstation, these hardware components are not physically present but are instead emulated by the hypervisor software.

When a user creates a 64-bit Linux guest VM in VMware Workstation, the default emulated disk controller is typically an LSI Logic 53c1030 SCSI controller. This device appears to the guest operating system as a standard PCI (Peripheral Component Interconnect) device, connected via the PCI bus. The hard disk itself is often just a large file (or set of files) on the host operating system. The guest interacts with this emulated controller using a specific driver, such as the MPT SPI driver (e.g., mpdsscsi in Linux kernel 6.19), which is designed to communicate with real-world LSI Logic hardware.

The SCSI specification is a complex standard that defines both the abstract commands and the physical electrical and optical interfaces. A critical part of SCSI communication is the CDB (Command Descriptor Block) protocol. Whenever a device needs to send a command to a hard disk or CD-ROM, it does so in the form of a CDB. These blocks typically have fixed lengths of 6, 10, 12, or 16 bytes. However, newer SCSI specifications introduced the concept of variable-length CDBs, allowing for more flexible and extended commands.

VMware's emulation of the LSI Logic controller involves a handler function that processes these incoming CDBs from the guest. This handler performs initial checks on the CDB, primarily examining its cdb_length and cdb_operation_code. The cdb_operation_code is the first byte of the CDB and specifies the command (e.g., "Test Unit Ready" is 0x00). These operation codes are divided into eight groups, with some groups (like Group 3, 6, and 7) being reserved or vendor-specific, and crucially, sometimes associated with larger or variable CDB lengths in newer specifications. The vulnerability stems from VMware's internal logic making incorrect assumptions about the maximum length of CDBs for certain operation codes, particularly those from Group 3, which could be exploited by a guest VM.

Key Findings

▶ Watch: Key observation: VMware physical memory mapping (22:00)

The central discovery of this research is CVE-2023-20872, an out-of-bounds read and write vulnerability affecting VMware Workstation. This flaw originates from a fundamental breakdown in assumptions within VMware's emulated LSI Logic SCSI controller handler. Specifically, the vulnerability arises when processing CDB (Command Descriptor Block) commands from a guest virtual machine.

VMware's code, designed to handle SCSI commands, contained a memcpy operation intended to copy the guest-provided CDB into an internal buffer. The critical flaw was in how the size for this memcpy was determined and validated. The cdb_length and cdb_operation_code are entirely controlled by the guest VM. While VMware had a check function that attempted to validate these values against an internal array of expected CDB lengths, this check was insufficient. For certain cdb_operation_code values, particularly those from Group 3, the check function would assume a cdb_length of 0x40 bytes based on its internal lookup table.

However, the internal buffer (A2, which points to the CDB array within a larger V6 structure) from which the memcpy sourced its data was assumed by the developer to be a maximum of 0x10 bytes. Similarly, the destination buffer for this memcpy was part of a larger allocation (e.g., a 0x58 byte chunk) but the specific buffer section intended for the CDB was also relatively small (e.g., 0x10 bytes). When a guest VM sends a CDB with an operation code from Group 3 and sets its cdb_length to 0x40, it successfully bypasses the length validation check. This leads to the memcpy attempting to copy 0x40 bytes:

1. Out-of-bounds Read: The memcpy reads 0x30 bytes beyond the assumed 0x10-byte boundary of A2 within the V6 structure. This constitutes an out-of-bounds read primitive, allowing the attacker to leak adjacent heap data.
2. Out-of-bounds Write: The memcpy also writes 0x40 bytes into the destination buffer. If the intended destination buffer is smaller than 0x40 bytes (e.g., 0x10 bytes for the CDB, followed by other data structures), this results in an out-of-bounds write, corrupting subsequent data on the heap. This could extend to 0x20 bytes into a "following chunk" on the heap, especially leveraging heap mechanisms like the Low Fragmentation Heap (LFH) on Windows.

This combination of out-of-bounds read and write primitives provides powerful avenues for exploitation, enabling information leakage (to bypass ASLR) and heap manipulation, ultimately leading to arbitrary code execution on the host. VMware addressed this vulnerability in Workstation version 17.0.2 with a "light fix" that specifically rejects CDBs with operation codes from Group 3, 6, and 7 that would result in larger-than-expected lengths, preventing the memcpy from being triggered with an oversized cdb_length.

Technical Deep Dive

▶ Watch: Live demonstration of Linux and Windows exploits (34:00)

The vulnerability, CVE-2023-20872, resides within the LSI_Logic_53c1030 emulation logic, specifically during the handling of CDB (Command Descriptor Block) commands. The core issue lies in a memcpy call where the source, destination, and size parameters are not correctly validated against each other.

The process begins with the guest VM sending a SCSI command. This command is encapsulated in a CDB, which includes a cdb_operation_code (the first byte) and a cdb_length. Both of these values are controlled by the guest. VMware's emulation code includes a check function that attempts to determine the expected length of the CDB based on its cdb_operation_code. This check uses a hardcoded array where, for instance, operation codes belonging to Group 3 are associated with an assumed length of 0x40 bytes.

The problem arises in the actual memcpy operation:

memcpy(destination_buffer, A2, cdb_length)

Here's a breakdown of the critical components:

• A2: This is a pointer to the guest-provided CDB data, which is stored as part of a larger, internally allocated structure, V6 (approximately 0x158 bytes in size). The developer's assumption was that the cdb data within A2 would not exceed 0x10 bytes.
• cdb_length: This is the length value specified by the guest. Due to the flawed length check, a guest can set this to 0x40 bytes for Group 3 operation codes.
• destination_buffer: This is a separate buffer, often part of a 0x58-byte chunk, but the portion specifically intended for the CDB data might be smaller, such as 0x10 bytes, followed by other internal data structures.

When the guest crafts a CDB with a Group 3 cdb_operation_code and a cdb_length of 0x40, the memcpy proceeds as follows:

1. Out-of-Bounds Read Primitive: The memcpy reads 0x40 bytes starting from A2. Since A2 was only designed to hold 0x10 bytes of CDB data, this operation reads 0x30 bytes (0x40 - 0x10) beyond the intended boundary of A2 within the V6 structure. This allows an attacker to read adjacent heap metadata or other sensitive information, crucial for bypassing ASLR (Address Space Layout Randomization). The speaker noted that at least 8 bytes from an adjacent chunk's header could be leaked.
2. Out-of-Bounds Write Primitive: Simultaneously, the memcpy attempts to write these 0x40 bytes into the destination_buffer. If the destination_buffer (or the section allocated for the CDB within it) is, for example, 0x10 bytes, this results in an overwrite of 0x30 bytes beyond its boundary. The speaker illustrated that this could overwrite subsequent internal elements (e.g., two 0x10-byte elements) and then extend up to 0x20 bytes into an entirely "following chunk" on the heap. This capability is extremely powerful for corrupting heap structures, manipulating pointers, or altering program flow. On Windows, this could leverage the Low Fragmentation Heap (LFH) to place attacker-controlled data adjacent to the target buffer.

The most potent primitive derived from this vulnerability is the Arbitrary Call. Within the larger V6 structure, there exists a function pointer. By leveraging the out-of-bounds write, an attacker can overwrite this function pointer with an arbitrary address. Crucially, the speaker identified that the function pointer is called with A10 (which is the V6 chunk itself) as the first parameter, and the second parameter is also controllable via the overflow. This means an attacker can control both the target function address and one of its arguments. If the function pointer is set to 0x0, the call is skipped, allowing for information gathering before triggering the final execution.

VMware's fix for CVE-2023-20872 in Workstation 17.0.2 was a "light fix." Instead of a full redesign of the CDB parsing logic, they implemented a specific check at the beginning of the handler. This check explicitly identifies cdb_operation_code values that would result in cdb_length values of 0x40 or 0x41 (associated with Group 3, 6, and 7) and immediately rejects them, preventing the oversized memcpy from occurring. This ensures that any processed CDBs have a length less than 0x10 bytes, thus avoiding the out-of-bounds conditions.

Demo / Proof of Concept

▶ Watch: Key takeaways and advice for bug hunting (38:00)

Wenxu Yin demonstrated the practical exploitation of CVE-2023-20872 on both Linux and Microsoft Windows guest virtual machines, achieving code execution on the host. The exploitation process varied significantly due to the differing security mitigations on each operating system.

A key observation underpinning both exploitation paths was the unique physical memory address mapping within VMware Workstation. Yin discovered that a guest VM's physical memory is not randomly mapped but is instead linearly mapped into the host's vmx process virtual address space. For example, if a guest has 4GB of RAM, its physical addresses (e.g., 0x0 to 0x8FFFFFFF) correspond directly to a specific, contiguous region within the vmx process's memory. This allows an attacker to precisely place arbitrary data structures (like command strings or ROP chains) directly into the guest's physical memory, knowing exactly where they will reside in the host's vmx process memory. This greatly simplifies the setup of exploit payloads, eliminating the need to find writable regions on the host.

Linux Exploitation

On Linux hosts, the exploitation was relatively straightforward due to the absence of Control Flow Guard (CFG), a mitigation that restricts indirect calls. With the powerful arbitrary call primitive derived from the out-of-bounds write, the attacker gained control over a function pointer and one of its parameters.

The strategy involved:

1. Gadget Discovery: Yin searched for a suitable ROP (Return-Oriented Programming) gadget. A working gadget was found that moved the second function parameter (which the attacker controlled) into the first parameter, and then called the function pointed to by this first parameter. This effectively gave the attacker control over both the target function and its first argument.
2. Payload Placement: Leveraging the physical memory mapping observation, the command string (e.g., for launching a calculator) was placed directly into a known physical memory address within the guest.
3. Arbitrary Call Execution: The controlled function pointer was set to the address of the identified ROP gadget (offset from the text segment of the vmx process). The second parameter was pointed to the physical memory location containing the command string.
4. System Call: The ROP gadget would then effectively call system() with the attacker-controlled command string as its argument, leading to the execution of a calculator on the Linux host. Yin noted that directly calling system@PLT sometimes had stack alignment issues, making the gadget approach more reliable.

The demonstration showed a calculator popping up on the Linux host, confirming successful code execution with a "very high success rate."

Windows Exploitation

Exploiting the vulnerability on Windows was more challenging due to the presence of Control Flow Guard (CFG), which validates indirect call targets. CFG typically ensures that indirect calls only jump to legitimate function entry points.

Yin's ingenious bypass for CFG involved:

1. Crash Analysis: While experimenting with the out-of-bounds primitive, Yin observed crashes. Analyzing the call stack of these crashes, he identified a specific internal vmx function (referred to as sub_140134F40 in the transcript, or "this guy").
2. CFG Bypass Function: This function had a peculiar characteristic: its first parameter (A1) was unused, but its second parameter (A2) was directly used as a function pointer. CFG primarily protects indirect calls where the first argument is the target of the call. By finding a function where a later argument (A2) was used as the function pointer, the attacker could effectively bypass CFG's checks.
3. Arbitrary Call Chain: The arbitrary call primitive was used to overwrite the function pointer in V6 with the address of this identified CFG-bypassing function. The second parameter to this call was then pointed to a specially crafted structure located in the guest's physical memory (again, using the linear mapping observation). This structure contained another function pointer (e.g., to WinExec) and its parameters (e.g., "calc.exe").
4. WinExec Execution: The CFG-bypassing function would then execute WinExec with the attacker-controlled parameters, leading to the execution of calc.exe on the Windows host.

The Windows demonstration also successfully launched a calculator, albeit quickly, as the vmx process often crashed immediately after execution. Yin acknowledged that for a real-world exploit, additional steps would be needed to defeat ASLR (e.g., using the out-of-bounds read for information leakage) to obtain the runtime addresses of functions like WinExec, but this was beyond the scope of the "hacking style" code execution demo.

Defensive Implications

▶ Watch: Q&A: Impact of varying guest RAM size on exploit (45:50)

The discovery and exploitation of CVE-2023-20872 underscore several critical defensive implications for hypervisor security:

• Prompt Patching: The most immediate defensive action is to apply the patch released by VMware. Users of VMware Workstation should update to version 17.0.2 or later to mitigate this specific vulnerability. Similar vulnerabilities might exist in other VMware products or other hypervisors, so keeping all virtualization software up-to-date is paramount.
• Hypervisor Complexity: Emulated hardware, particularly complex devices like disk controllers, presents a vast attack surface. Their intricate specifications, coupled with the need for high performance and compatibility, often lead to subtle bugs. Defenders should be aware that these components are prime targets for sophisticated attackers seeking VM escape capabilities.
• Specification Auditing: This vulnerability highlights how deviations or incomplete understanding of evolving hardware specifications (like variable-length CDBs in SCSI) can introduce critical flaws. Security auditors and developers should perform thorough reviews of how emulated devices interpret and validate guest-provided commands against the full and up-to-date hardware specifications.
• Driver Analysis: The speaker emphasized the utility of analyzing the guest operating system's drivers (e.g., mpdsscsi for LSI Logic controllers) for emulated devices. These drivers often mirror real-world hardware interactions, providing clues on how the hypervisor's emulation might be challenged or fuzzed.
• Fuzzing and Code Auditing: The complexity of disk controller emulation makes them ideal candidates for continuous fuzzing and manual code auditing. Tools that generate malformed or unexpected SCSI commands could uncover similar logic flaws.
• Host-Level Monitoring: While VM escape aims to bypass hypervisor defenses, host-level monitoring solutions can still play a role. Unusual process spawns (like a calculator) originating from the vmx process, or unexpected memory access patterns, could indicate a successful escape attempt. However, this is often a post-exploitation detection.
• Layered Security: Relying solely on hypervisor isolation is insufficient. Implementing layered security, including host OS hardening, network segmentation, and endpoint detection and response (EDR) solutions, provides additional barriers against an attacker who has achieved a VM escape.

Key Takeaways

• Emulated hardware is a complex attack surface: Disk controllers and other emulated devices are highly intricate, making them fertile ground for vulnerabilities that can lead to VM escape.
• Specifications are paramount: Thoroughly understanding and correctly implementing hardware specifications (e.g., SCSI CDB protocol, including variable-length CDBs) is crucial to prevent security flaws.
• Guest-to-host memory mapping is an exploit enabler: The linear mapping of guest physical memory into the host vmx process's virtual address space on VMware Workstation significantly simplifies exploit payload placement and execution.
• Creative CFG bypasses are essential on Windows: While Control Flow Guard (CFG) is a strong mitigation, specific function characteristics (like an unused first parameter but a controllable second parameter as a function pointer) can be leveraged to bypass it.
• Arbitrary call primitives are powerful: Gaining control over a function pointer and its arguments (even partially) is a highly effective primitive for achieving code execution.
• Patching is critical: CVE-2023-20872 (fixed in Workstation 17.0.2) highlights the continuous need for users to keep their hypervisors updated to protect against guest-to-host escape vulnerabilities.

About the Speaker(s)

Wenxu Yin is a distinguished Vulnerability Researcher at Qihoo 360 Alpha Lab. His extensive background in cybersecurity research spans multiple domains, starting with bug hunting in network devices from prominent vendors like Juniper, SonicWall, and Netgear. In recent years, Yin has shifted his focus to the challenging field of hypervisor security, where he actively pursues vulnerabilities in platforms such as VMware Workstation and QEMU. His expertise is recognized through his team's multiple championships in prestigious Pwn2Own events, demonstrating his exceptional skills in discovering and exploiting complex software vulnerabilities. Yin's work emphasizes deep technical analysis and innovative exploitation techniques, making significant contributions to the understanding and mitigation of critical security flaws in virtualization environments.