VMware’s Launch escape SYSTEM
December 21, 2017 | Abdul-Aziz HaririThis is the fourth blog in our series of Top 5 interesting cases from 2017. Each of these bugs has some element that sets them apart from the approximately 1,000 advisories released by the program this year. Today’s post details a bug that allows attackers to escape a virtual guest machine and execute code on the hypervisor.
Overview
For Pwn2Own 2016, we introduced VMware as a new target category in the contest. Unfortunately, no contestant attempted to escape VMware’s isolation that year. It seems that the inclusion of virtual machine escapes came as a surprise to potential contestants. However, since we introduced it at Pwn2Own, we started receiving VMware submissions through the Zero Day Initiative program and saw two successful VMware escapes at Pwn2Own 2017.
One of the best VMware submissions we received in 2017 was ZDI-17-921/CVE-2017-4934. The vulnerability affects the VMware NAT Service (vmnat.exe). What’s remarkable is that the last vulnerability found in this service dates back to 2005. This twelve-year gap in public discoveries highlights that this code has not gone through a thorough audit by the research community.
Also, the most important part of this vulnerability stems from the fact that vmnat.exe runs with SYSTEM privileges on the host OS. That is right – an attacker can leverage this vulnerability to elevate privileges outside of the virtual machine and execute arbitrary code under the context of SYSTEM on the host.
This vulnerability was found and submitted to us by Jun Mao of Tencent PC Manager.
The bug
The vulnerability existed due to the lack of input validation when reassembling IP fragments. The vmnat service allocates a fixed sized heap buffer to store IP fragments. The heap buffer allocated accommodates a maximum of 256 fragments. Sending an IP packet with more than 256 fragments would end up overflowing the buffer.
The target object we’re overflowing is of size 0x844, which can be confirmed by both debugging and static reverse engineering in IDA:
As mentioned before, this object is used to store the packet fragments. The following code shows the write followed by incrementing the fragment counter.
In order to hit the vulnerable code, we will need to set ip_frag_offset with specific values to take the loc_4059C5 branch:
By crafting the packets carefully, we will end up with the following crash in vmnat.exe:
As you can see from above, the 32-bit vmnat.exe process has crashed when trying to write memory past the end of a heap allocation. To exploit this, the attacker will need to properly massage the heap in a way that will place attacker controlled buffers after this allocation then trigger that vulnerability. We will leave these steps as an exercise for the reader. ☺
Conclusion
Over the past year, we saw a rise in VMware submissions. Most of them were interesting, but this vulnerability definitely stands out because of its criticality. Successfully exploiting this vulnerability will not only get you code execution on the host, it will also get you SYSTEM privileges. VMware patched this vulnerability in Workstation version 12.5.8 and in Fusion version 8.5.9.
VMware Workstation and Fusion are becoming required tools for information security practitioners, and we believe more public research needs to be done to close off these gaps. Cheers to Jun Mao of Tencent PC Manager for a great submission!
You can find me on Twitter at @AbdHariri, and follow the team for the latest in exploit techniques and security patches. Check back tomorrow for the final bug in our list of the Top 5 Bugs of 2017!