exploit the possibilities

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
MD5 | d2417f8af8ebed99ebd6fdfff7a2c153

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:

January 2022

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close