Overview ======= We identified several security issues in the ESIx virtual machine monitor (VMM): a use-after-free (UAF) vulnerability in PVNVRAM, a missing return value check in EHCI USB controller leading to private heap information disclosure, and several OOB reads. All issues have been fixed by the vendor. Links to the patches are provided below. ESXi PVNVRAM Use After Free [CVE-2020-3963] ====================================== The paravirtualized NVRAM device supports read / write / find-next operations on variables stored in its variables store. The find-next operation (opcode 0xD2) allows guest firmware to enumerate all variables in the store by querying for the next variable in the store. PVNVRAM stores a raw pointer to the last returned variable. In most places that update the variable store, this pointer is properly cleared, however, in the write operation (opcode 0xD3), there’s a flow that updates / deletes an existing variable, where this last_search_value pointer is not cleared. This leads to a situation where the dangling pointer is used in subsequent find-next operations. We were able to trigger this UAF from the guest, and confirmed (using gdb) that the dangling pointer is indeed used after free. https://www.vmware.com/security/advisories/VMSA-2020-0015.html ESXi EHCI qTD data leak [CVE-2020-3964] ================================= The EHCI USB controller processes queue element transfer descriptors (qTD), as described in section 3.5 of the EHCI specification. We found that the implementation in this case processes guest-controlled qTDs. Each descriptor has up to 5 buffer pointers that together hold the USB request block (URB): +---------Queue Element Transfer Descriptor Block + | Next qTD pointer | 0 | T | | Alternate Next qTD Pointer | 0 | T | | Total Bytes to Transfer | C_Page | Cerr | Status | | Buffer Pointer (page 0) | Current Offset | | Buffer Pointer (page 1) | Reserved | | Buffer Pointer (page 2) | Reserved | | Buffer Pointer (page 3) | Reserved | | Buffer Pointer (page 4) | Reserved | +----------------------------------------------------+ The function EhciReadTDBuffer() (name identified from log string) reads the URB contents into a heap allocated buffer. Unfortunately, the return value of ReadBytes is not checked. A guest can cause this function to fail by passing a GPA value of zero (or, in the 64bit addressing case, a non-canonical address >= 0x8000’0000'0000). This leads to a case where an attached USB device processes a URB with uninitialized heap data. We successfully exploited this to leak VMM heap data by sending a SCSI WRITE command to a USB mass storage device. Writes to a USB mass storage device are encoded in two qTDs: the first holds the SCSI WRITE header, and the second holds the data to be written. For example, the following operations in the guest: $ perl -e "print 'a'x2000;" > aaaa $ sudo dd if=aaaa of=/dev/sdb1 bs=512 count=8 Result in the following qTDs: # # First qTD of size 0x1f: # "USBC" signature is the CBW packet header set by # usb_stor_Bulk_transport() in drivers/usb/storage/transport.c. # # 0x2A is SCSI WRITE (10) command in the CDB buffer. # 0x08 is the transfer length in sectors (8 * 0x200 = 0x1000). # Thread 1 hit Breakpoint 1, xxxx in ?? () EhciReadTDBuffer, buffer pointer 1 = 34a89000, size = 1f Thread 1 hit Breakpoint 2, xxxx in ?? () => 0x65f38a8: 0x55 0x53 0x42 0x43 0x5f 0x03 0x00 0x00 0x65f38b0: 0x00 0x10 0x00 0x00 0x00 0x00 0x0a 0x2a 0x65f38b8: 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x08 0x65f38c0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 # # Second qTD of size 0x1000 holds the "aaaaaa" data: # Thread 1 hit Breakpoint 1, xxxx in ?? () EhciReadTDBuffer, buffer pointer 1 = 33a82000, size = 1000 Thread 1 hit Breakpoint 2, xxxx in ?? () => 0x65e1728: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x65e1730: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x65e1738: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x65e1740: 0x61 0x61 0x61 0x61 0x61 0x61 0x61 0x61 By failing ReadBytes() in the second qTD, we write previous heap data to the disk. We verified VUsb_NewUrb() mallocs the URB buffer, and doesn’t memset the data buffer to zeros. We confirmed that by reading back the disk contents, the hypervisor was leaking uninitialized heap data. https://www.vmware.com/security/advisories/VMSA-2020-0015.html ESXi XHCI OOB read access [CVE-2020-3965] ==================================== XHCI USB controller reads the DCBs from the guest by mapping a guest page and iterating over values in it based on a bit field value. There was insufficient validation on the bit field value: the map size may be out of sync with the loop counter. A guest can supply a size value of 0x40, with a bit field value of 0xffffffff. This causes the loop to copy 32 elements out of the mapped page, which is outside the bounds of the mapped region https://www.vmware.com/security/advisories/VMSA-2020-0015.html ESXi NVME OOB read access [CVE-2020-3960] ========================================== The NVME controller does not properly handle namespace 0 in the nvme_admin_identify handler. NSID of 0 minus one underflows and leads to an OOB read access. https://www.vmware.com/security/advisories/VMSA-2020-0012.html Credits =========== These vulnerabilities were discovered and reported to VMware by Cfir Cohen of the Google Cloud security team. Timeline ======== 4-20 - Vulnerabilities disclosed to VMware security team 4-26 - Vendor confirms the issues 6-09 - VMSA-2020-0012 fixes NVME issue 6-23 - VMSA-2020-0015 fixes PVNVRAM, EHCI, XHCI issues 7-16 - Public disclosure We’d like to thank the VMware security team for their prompt response.