vmware漏洞之四：简评USE-AFTER-SILENCE: EXPLOITING A QUIETLY PATCHED UAF IN VMWARE

转：https://www.zerodayinitiative.com/blog/2017/6/26/use-after-silence-exploiting-a-quietly-patched-uaf-in-vmware

Springtime around the Zero Day Initiative (ZDI) means ramping up for the Pwn2Own (P2O) competition held each year at the CanSecWest conference. To say the least, it’s a busy time to be a ZDI researcher as we build targets, answer contestant questions, and review program submissions. This year was no different. In 2016, we introduced the VMware escape category in P2O but did not have any entries. We were expecting some for 2017, so it did not surprise us when we received a VMware vulnerability through the program a week before the contest.

I was very curious about this vulnerability for various reasons. First, I thought it was a defensive submission of some sort, one meant to possibly create a duplicate at P2O, thus preventing another competitor from getting a full P2O win. This has happened in the past and adds a new level of strategy to the P2O contest. Second, and most importantly, it was a Use-After-Free (UAF) vulnerability affecting drag-and-drop (DnD) and was triggered by Remote Call Procedure requests, which is something I’ve never played with before.

This blog covers the vulnerability and the efforts put into exploiting it. It’s also the first in a series of blogs that will discuss various VMware topics, including exploitation, reversing, and fuzzing VMware targets. Going from a virtual client to executing code opens a new world of possibilities – and risks.

Note: This vulnerability existed on VMware Workstation 12.5.2 and earlier versions. It was subsequently patched with VMware Workstation version 12.5.3. All the analysis shown here was done on VMware Workstation 12.5.1.

The bug

Before I explain the details of the bugs involved, here’s a quick video showing the full exploit chain in action:...

The nice thing about this vulnerability was how simple it was to trigger. Sending the following RPCI requests triggered the vulnerability:

tools.capability.dnd_version 2
    vmx.capability.dnd_version
    tools.capability.dnd_version 3
    vmx.capability.dnd_version
    dnd.setGuestFileRoot AAAAA //Technically any DnD function would work.

With pageheap fully enabled on vmware-vmx.exe, WinDbg would break with the following exception:（这个出错的地方存疑？复现地址不一样！）

Reviewing the output from !heap (pronounced bang-heap) gave me more information about the address in @RCX. First, I learned that it was indeed a Use-After-Free, and second, I knew exactly where the free happened:

 

The next step was to determine the size of that object.(上图中的sub_1400A2cf0并没有出现在！heap结果中？) By breaking right before the free happened and running !heap on @RCX, this gets me the information I was looking for:

 

The disassembly above showed that the freed object was of size 0xb8 . By examining the instructions around the crash（通过在crash周围的指令可以发现该对象被另一个初始化对象所引用）, I noticed that the dangling pointer was kept in an object of size0x38（该指针在0x38的对象中存储） , which was allocated initially when the VM starts:

Exploiting the bug

While examining the disassembly at crash time, it was obvious that I needed some kind of information leak to exploit this vulnerability. To speed up this process, I used one of Tencent Security's Pwn2Own（借助了腾讯漏洞CVE-2017-4905来绕过aslr.如果不用呢，能否实现利用？） vulnerabilities that leaked the address of vmware-vmx.exe. This particular info leak will be discussed in detail in the future, but it does provide the needed info leak to make this exploit successful.

Usually, when I try to exploit vulnerabilities in a target, I ask myself these questions:

1. What type of requests can I send?
2. What do I control?
3. How can I control the crash?
4. How can I gain better exploitation primitives?

At this point, I could send RPCI requests, which are technically sent through the Backdoor interface along with other Backdoor requests. Yes, the official name VMware gave this interface is Backdoor.

So, how could I control the contents of the freed object? I’m used to UAF’s in the browser world, but exploiting and controlling this one was something new to me. I started looking at the RPC functions that I can call from the Guest with normal user privileges, and I stumbled across tools.capability.guest_temp_directory . I thought it would be easy to send a string of a certain size to overwrite the freed block. The result was promising:

（注意占位了可能还会释放。需要多次发送请求，增大占位的概率。tools.capability.guest_temp_directory aaa;aaa多次执行后，前面的数据会被清除。）

Technically, we can control this vulnerability by sending an arbitrary RPC request, though not necessarily tools.capability.guest_temp_directory . This solves the biggest problem.

The next question was whether or not I could put a ROP chain and payload in a deterministic place. Again, I started looking at the RPC functions that I could call from the Guest. There were a few interesting functions to choose from.(看来还得逆向分析查看) The one that stood out was unity.window.contents.start . Taking a closer look at the assembly, I noticed that a reference to the contents is kept in a global variable:

 

In other words, if I sent a unity.window.contents.start request, I’d know exactly where this request was stored: vmware_vmx+0xb870f8.

So, I triggered the crash again with the following RPC calls:

tools.capability.dnd_version 2
    vmx.capability.dnd_version
    tools.capability.dnd_version 3
    vmx.capability.dnd_version
    unity.capability.guest_temp_directory AAA..AAAA
    dnd.setGuestFileRoot BBB..BB

As you can see, @RDI points to the request that triggered the bug.(也就是假如请求中包含shellcode，则shellcode存储地址可预测，即就是rdi.那么假如控制了跳转地址，则将其跳转到rdi也就是shellcode。)

What did the plan look like at this point?

1. Send a unity.window.contents.start request with a ROP chain that sets RSP to RDI.（只需将rsp指向rdi.这样就可以rop了，这是栈迁移）
2. Trigger the free.（释放对象）
3. Overwrite the freed object with another one. The freed object should contain the address of vmware_vmx+0xb870f8.（占用对象。包含指向栈迁移的地址）
4. Trigger the re-use using a request that contains the ROP chain to gain RCE.

Visually, it’s pretty simple:

 

The resulting code execution leaves the virtual client behind to instead run at the hypervisor layer.

Conclusion

When we introduced the VMware category at Pwn2Own 2016, we didn’t really expect to get any entries. We rarely see entries in new categories due to the time it takes researchers to find bugs and craft the needed exploits. However, we were hopeful that we would see some appear in 2017, and sure enough, two different teams successfully elevated from virtual client to executing code in the hypervisor. I’ll be detailing those exploits and techniques in the future. Until then, don’t let Use-After-Free vulnerabilities in VMware scare you. They’re fun to exploit ☺. Every RPCI function has its own story with its own exploit primitive.

You can find me on Twitter at @AbdHariri, and follow the team for the latest in exploit techniques and security patches.