Critical VMware VMSA-2020-0023. Explained & Covered.

Yesterday (20. 10. 2020) VMware released a new VMware Security Advisory, VMSA-2020-0023 marked with Critical severity. Unfortunately, VMware continues in practice to release one VMSA for multiple CVEs (6 this time) with different severities and affecting different products, so it is not easy to evaluate that quickly. Common Vulnerabilities and Exposures (CVE) is a dictionary that provides definitions for publicly disclosed cybersecurity vulnerabilities and exposures.. Should you be scared? Here is a short summary of what is inside.


ESXi OpenSLP remote code execution vulnerability (CVE-2020-3992)

CVE-2020-3992 is the only one of these marked as critical. This can be used by an attacker with access to the network. The OpenSLP service running on port 427 running on the ESXi host is vulnerable. The Service Location Protocol is a service discovery protocol that allows computers and other devices to find services in a local area network without prior configuration. On the ESXi host, this is used by the hardware health monitoring service. A few CVEs were already released for the service in the past. VMware released patches for ESXi 6.5, 6.7, and 7.0. As a workaround, you can disable the service and close the port, as is described in the VMware KB 76372. Don't be surprised if the hardware health monitoring stops working for you! Since the attacker needs “just” access to the network and list of hosts or possibility to scan ports, this seems to be scary and at least the workaround should be applied. As always, defence in depth should be in place, with the management network segregated from the workloads at a minimum.



TOCTOU out-of-bounds read/write vulnerability (CVE-2020-3981 and CVE-2020-3982)

CVE-2020-3981 and CVE-2020-3982 are marked as important and moderate severity respectively. Time-of-check-to-time-of-use (TOCTOU) happens when the object is changed between checkin it and using it by the system. An attacker with administrative access to a virtual machine may be able to exploit these issues to leak memory from the vmx process, to crash the virtual machine's VMX process, or corrupt the hypervisor's memory heap. Affected are ESXi, VMware Fusion, and Workstation. There is no workaround, though patches are available for affected products. The attacker needs administrator rights to the virtual machine to be able to exploit the vulnerability, so you should be scared, but just a bit. Least privilege helps here.



VMCI host driver memory leak vulnerability (CVE-2020-3995)

CVE-2020-3995 is marked as important. The VMCI host driver contains a memory leak vulnerability. An attacker with access to a virtual machine may be able to trigger a memory leak issue resulting in memory resource exhaustion on the hypervisor. This affects ESXi 6.5, 6.7, VMware Fusion, and Workstation. Patches fixing the issue are available for download. The attacker is able to crash your ESXi host using a normal user account inside the virtual machine, so you should be a bit scared.



vCenter Server session hijack vulnerability in update function (CVE-2020-3994)

CVE-2020-3994 is marked as important. vCenter server appliance Management Interface session can be hijacked during the download of vCenter updates because certificates are not validated in this phase. Affected are vCenter Server appliances 6.5 and 6.7. Fixed versions are available for download, and detailed in the VMSA. Obviously, we would recommend that you download the patches to another machine and perform an offline patch/update, else there is the risk of you being affected by this vulnerability in the process of remediation. Hijacking vCenter management will give quite high power to the attacker’s hand, fortunately he would have to have good timing and attack you exactly during the vCenter update process. Be careful and update offline this time.



NSX-T MITM vulnerability (CVE-2020-3993)

CVE-2020-3993 is marked as important. This allows a man in the middle attack (situation when the attacker secretly relays and possibly alters communication between two devices) to the KVM-based NSX-T transport node which can be compromised. Patches are available. If you are not using KVM as transport nodes, then you are fine, otherwise you should update as soon as possible.


Where automatic updates are enabled, Runecast Analyzer users should already have this VMSA covered, with offline updates available through the Runecast customer portal as usual. We have decided to split the announcements in the VMSA into separate findings for better readability, and to help our customers to identify risk levels for each of their affected components.


About the Author | Martin Rehula

Martin is a VMware Engineer at Runecast. He started his career as a UNIX admin, but when he touched VMware ESX (way back in the v2.5 days) for the first time, he decided to stay in the virtualization realm. He has been an admin in VMware and Citrix based virtual environments with a focus on centralized management and automation at Tieto and Hella. You might meet him roaming a city, forest, or mountains – hunting the decisive moment and point to be captured by his camera. Find him on Twitter as @virt4all.

Never miss new blog post!