Last fall, I reported two critical-rated, pre-authentication remote code execution vulnerabilities in the VMware ESXi platform. Both of them reside within the same component, the Service Location Protocol (SLP) service. In October, VMware released a in November completely addressing the use-after-free (UAF) portion of these bugs. The UAF vulnerability was assigned CVE-2020-3992. After that, VMware released a third ) is a network service that listens on TCP and UDP port 427 on default installations of VMware ESXi. The implementation VMware uses is based on from the original OpenSLP project.
The Patch for CVE-2021-21974
Six weeks later, the third patch (build- 17325551) was released. It addressed the root cause of the heap overflow bug by checking the length before the memcpy at (6).
Exploitation
All Linux exploit mitigations are enabled for /bin/slpd, and most notably, during which sendbuf can survive due to the select-based socket model:
- Fill a socket send buffer without receiving until the send buffer is full.
- Partially overwrite
sendbuf->curposfor that socket. - Start to receive from the socket. The leaked memory will be appended at the end.
There are some additional challenges, though:
-- Due to the use of strstr(), you cannot overflow with a NULL byte.
-- The overflowed buffer (obuf) will be automatically to sendbuf->start in preparation for the memory disclosure.
sendbuf->start with 2 NULL bytes, where sendbuf belongs to the connection mentioned in step 1. Start receiving from the connection. You can then get memory disclosure, including the address of sendbuf.sendbuf->curpos from a new connection to leak the address of a recvbuf, which is allocated from mmap(). Once you have an mmapped address, it becomes possible to infer the libc base address.recvbuf->curpos from a new connection, setting it to the address of free_hook. Start sending on the connection. You can then overwrite free_hook.free_hook to start the ROP chain.These steps may not be the optimized form.
Privilege Level Obtained
If everything goes fine, you can execute arbitrary code with root permission on the target ESXi system. In ESXi 7, a new feature called DaemonSandboxing was prepared for SLP. It uses an AppArmor-like sandbox to isolate the SLP daemon. However, I find that this is disabled by default in my environment.
This suggests that a sandbox escape stage will be required in the future.
Conclusion
VMware ESXi is a popular infrastructure for cloud service providers and many others. Because of its popularity, these bugs may be exploited in the wild at some point. To defend against this vulnerability, you can either apply the relevant . You should consider applying both to ensure your systems are adequately protected. Additionally, VMware now recommends disabling the OpenSLP service in ESXi if it is not used.
We look forward to seeing other methods to exploit these bugs as well as other ESXi vulnerabilities in general. Until then, you can find me on Twitter for the latest in exploit techniques and security patches.
SOCIAL SHARE CARD GENERATOR