SLP is no longer enabled by default, and ESXi is now sandboxing more and more user-mode processes. For these reasons, ESXi kernel bugs have not been a popular topic of discussion, at least not publicly. On the other hand, user-mode daemons such as SLPD run with the highest privileges (i.e., superDom), so in the case of compromise of a daemon, there is no need for further escalation. ESXi has no login shell for low-privileged users, so that entry point is eliminated. Historically, kernel privilege escalation vulnerabilities in ESXi have not been frequently seen. This option enables keep-alive messages on connection-oriented sockets. Of particular note are differences in the handling of the SO_KEEPALIVE socket option. Additionally, I also explore ESXi’s kernel heap allocator and weaknesses in existing kernel mitigations.įor information regarding the initial analysis of the TCP/IP kernel module, VMkernel debug symbols, and porting type information from FreeBSD to ESXi, it is recommend to read our earlier analysis.įirst, let’s take a look at how ESXi 6.7 build 19195723’s setsockopt implementation differs from that of FreeBSD.
The vulnerability was assigned CVE-2022-31696 and disclosed as part of the advisory VMSA-2022-003. This blog post details a vulnerability I discovered in ESXi’s implementation of the setsockopt system call that could lead to a sandbox escape. While our focus was mainly on missing FreeBSD patches in ESXi, we also came across a type confusion bug in code introduced by VMware. Last year we published our patch gap analysis of ESXi’s TCP/IP stack, which is forked from FreeBSD 8.2.
0 kommentar(er)
