Several security issues have been identified in the VMware 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 out-of-bounds reads.
d2417f8af8ebed99ebd6fdfff7a2c153Overview
=======
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.