ESXi CIM Services Authentication Bypass and Remote Code Execution Vulnerabilities

Earlier this year I discovered two security vulnerabilities in ESXi 5.0 that allow an attacker to bypass authentication controls in one of the ESXi CIM network services, or to execute arbitrary code. Further investigations showed that these vulnerabilities were also present in the earlier releases of vSphere 4.0 and 4.1.

The initial public disclosure of these vulnerabilities follows.

I gratefully acknowledge the assistance of JPCERT/CC and AusCERT in assisting with a report to VMware and preparing for disclosure.

Summary

Two closely-related vulnerabilities have been discovered in the CIM broker included in a number of versions of VMware ESXi:

  1. CVE-2013-3657: A buffer overflow flaw exists that allows an unauthenticated remote attacker to overwrite part of the stack and may allow execution of arbitrary code as root in the ESXi shell.
  2. CVE-2013-3658: A directory traversal flaw exists that allows a remote attacker to bypass authentication controls and may allow an attacker to cause VM or hypervisor files at arbitrary paths to be deleted.

To exploit the vulnerabilities an attacker requires network access to TCP/IP port 5988 (local) or port 5989 via a vmkernel interface (remote).

This information may be updated with further details after there has been reasonable opportunity to correct the flaws in vulnerable systems or mitigate against exploitation.

Vulnerable

Releases and updates prior to March 2012 of

  • ESXi 4.0
  • ESXi 4.1
  • ESXi 5.0

are vulnerable.

VMware silently released patches around March 2012 that address these flaws.

It is believed that some versions of ESX 4.0 and ESX 4.1 are also vulnerable. Analysis of ESX 4.0 patches indicates this is the case and that VMware has attempted to address the vulnerabilities through patches.

Not vulnerable

ESXi 5.1 is not vulnerable.

The open source Standards Based Linux Instrumentation for Manageability Small Footprint CIM Broker (SBLIM sfcb) code – upon which VMware’s broker is based – does not contain the flaws.

Mitigation

  • CIM services may be disabled if not being used. Note: The hardware health functionality in vCenter Server Webservices uses ESXi host CIM services.

  • The ESXi firewall may be configured to limit access to CIM services.

Procedures vary depending on version. Consult VMware documentation or contact VMware in accordance with your entitlement if unsure.

External firewalls and other network filtering devices may be employed.

IMPORTANT

  • VMware has introduced binary incompatibility into its contributions to sfcb such that it is not possible to remove the vulnerabilities by using binaries from SBLIM alone.

  • The vulnerabilities may be exposed on vmkernel interfaces other than those configured for management traffic. It is not believed that the vulnerabilities can be exploited from a virtual machine network that is isolated from vmkernel networks.

Obtaining corrections

VMware has made available corrections in patch files:

  • ESXi 4.0: Patch 201203001
  • ESXi 4.1: Patch 201204001
  • ESXi 5.0: Update 1

VMware has not described either vulnerability in a security advisory or any public release notes to date, and has declined to make a coordinated public disclosure through a VMware Security Advisory.

Obtaining corrections in source code form

Although VMware has made some open source code available along with downloads of some versions of ESXi software, it has not included its corrections for these flaws in such downloads.

VMware customers and others who have been granted certain rights in the sfcb software under the Eclipse Public License may acquire the source code to it, including VMware’s contributions, by writing to VMware.

Corrected source code will also be made available here.

References and acknowledgments

JPCERT/CC has attempted to arrange coordinated disclosure with the vendor. The assistance of both JPCERT/CC and AusCERT is gratefully acknowledged.

Disclosure timeline

25th June 2013 – Vulnerability reported to vendor through JPCERT/CC

16th August 2013 – Vendor declined, via JPCERT/CC, to publicly disclose the vulnerabilities

24th August 2013 – Initial publication