本文将讨论各种VMware主题，包括利用，扭转和虚拟化VMware目标，从虚拟客户端到执行代码。

注意：VMware Workstation 12.5.2及更低版本中都存在此漏洞，不过随后的VMware Workstation 12.5.3版修补了这些漏洞。此处显示的所有分析都是在VMware Workstation 12.5.1上完成的。

漏洞分析

在我解释所涉及的漏洞的细节之前，请先浏览一下以下的视频：

 

这个漏洞的好处是它是能够简单的触发。发送以下RPCI请求触发了此漏洞：

在vmware-vmx.exe上完全启用了pageheap，WinDbg将会破坏以下异常：

查看bang-heap的输出给了我更多关于@RCX中的地址的信息。首先，我知道这确实是一种免费使用，其次，我确切知道发生了什么事情：

下一步是确定该对象的大小。

上面的反汇编表明，释放的对象大小为0xb8。通过检查崩溃的指示，我注意到悬挂的指针被保留在一个大小为0x38的对象中，最初是在VM启动时分配的：

利用漏洞

在崩溃时进行检查，显然需要某种信息泄露来利用此漏洞。为了加快这个检查过程，我使用了一个泄漏vmware-vmx.exe地址的腾讯安全公司的Pwn2Own漏洞。这个特定的信息泄漏将在将来详细讨论，但它确实提供了所需的信息泄漏，使得这个漏洞能够被成功利用。

通常，当我尝试利用目标中的漏洞时，我会问自己这些问题：

1.可以发送什么类型的请求？
2.我该怎么控制？
3.如何控制崩溃？
4.如何获得更好的开发原语？

在本文中，我可以发送RPCI请求，这些请求在技术上可以通过后门接口和其他后门请求一起发送。是的，VMware给这个界面的官方名称是Backdoor。

那么，我如何控制被释放对象的内容呢？我习惯了使用UAF (Use After Free)漏洞，它是一种内存破坏漏洞，通常存在于浏览器中在浏览器世界，但是利用和控制它对我来说是一件新的挑战。我开始查看RPC函数，我可以使用普通用户权限从Guest访问，并且我偶然看到了tools.capability.guest_temp_directory。我认为发送一定大小的字符串来覆盖被释放的代码块很容易。

从技术上讲，我们可以通过发送任意RPC请求来控制此漏洞，尽管不一定是tools.capability.guest_temp_directory。

下一个问题是我是否可以将ROP链和有效载荷置于确定性的位置。再次，我开始查看可以从Guest访问的RPC函数。有几个有趣的功能可供选择，这其中比较突出的是unity.window.contents.start。仔细看看本次比赛，你就会注意到对内容的引用保存是在一个全局变量中发生的：

换句话说，如果我发送了一个unity.window.contents.start请求，我将确切地知道这个请求的存储位置：vmware_vmx + 0xb870f8。

所以，我用以下RPC调用再次触发崩溃：

如上图所示，@RDI指向触发该漏洞的请求。

使用将RSP设置为RDI的ROP链发送unity.window.contents.start请求。

触发是的免费，用另一个覆盖被释放的对象。释放的对象应包含vmware_vmx + 0xb870f8的地址。使用包含ROP链的请求来触发重新使用以获取RCE。

所产生的代码执行将虚拟客户端放在虚拟机管理程序层之后。

总结

当在2016年的Pwn2Own中引入VMware时，其实并不希望获得任何条目。由于研究人员需要查找错误和处理所需漏洞的时间，我们很少看到新类别的条目。但是，在2017年的比赛中，就有两个不同的团队成功地从虚拟客户端升级到在虚拟机管理程序中执行代码。我将来在接下来几篇文章中详细说明这些漏洞和技术。