exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

VMware ESXi Use-After-Free / Out-Of-Bounds Access

VMware ESXi Use-After-Free / Out-Of-Bounds Access
Posted Jul 17, 2020
Authored by Google Security Research, Cfir Cohen

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.

tags | advisory, info disclosure
advisories | CVE-2020-3960, CVE-2020-3963, CVE-2020-3964, CVE-2020-3965
SHA-256 | 9736a651dce3d31a53e949929fa5e638854317668ea1eefa6f0e52872f79d3a2

VMware ESXi Use-After-Free / Out-Of-Bounds Access

Change Mirror Download
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.


Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close