记一次 VMware 的崩溃调试分析过程

Z时代
2024-01-10
分类：IT

作者：启明星辰ADLab

公众号：https://mp.weixin.qq.com/s/ODmXAZKz5JVitjzXpUdz9g

1 背景

VMware Workstation是一款主流的虚拟机软件，近期启明星辰ADLab安全研究员在使用VMware虚拟机的过程中遇到虚拟机异常崩溃的问题，当从7zip中直接将文件拖拽到VMware虚拟机中，会造成虚拟机异常关闭。目前已测试过VMware 15.5.0、15.5.2、15.5.5 以及7zip 19.0、20.02等版本。本文将通过对VMware和7zip程序进行跟踪分析，最终定位虚拟机异常关闭原因。

2 VMware端调试分析

使用WinDbg -I指令将WinDbg设置为即时调试器，VMware-vmx.exe程序崩溃后自动弹出WinDbg。堆栈信息如下：

调试信息显示stack buffer overrun异常，最初推断可能是缓冲区溢出漏洞。

通过查询资料后发现，从Windows 8开始，Windows设计了一个新的中断INT 29H，用以快速抛出失败，在sdk中被声明为fastfail， fastfail内部函数不会返回。

体系结构	指令	代码参数的位置
x86	int 0x29	ecx
x64	int 0x29	rcx
ARM	操作码 0xDEFB	r0

在上图中，程序终止于int 29h，而它的参数为0xa，对应FAST_FAIL_GUARD_ICALL_CHECK_FAILURE，由此推断问题可能出现在CFG的检查过程中。

从函数调用栈中vmware_vmx+0x58b21地址向上追溯，动态调试程序，比较程序正常运行与异常崩溃的函数调用区别，定位到与程序崩溃相关的函数sub_1400965A0。

使用Windbg Attach vmware-vmx.exe程序，在sub_1400965A0函数设置断点，开始动态调试。从7z打开的压缩文件中拖拽cdp.pcapng的文件，程序在断点处停下。通过动态调试可知该函数中calloc分配了三个堆空间，分别用于存放：主机临时文件路径temp_path、目标文件名file_name以及VMware中的缓存目录名vm_cache_dir_name。

但是打开主机Temp目录下却没有发现该文件，于是初步断定这是程序崩溃原因。继续往下看，3个文件相关参数全都传入了sub_140579b30函数。

进入函数sub_140579b30，定位temp_path参数的处理。其中，sub_14057FF90函数对传入的temp_path进行了逐一遍历，sub_1405B2080函数对传入的temp_path进行了非法性检查。下面重点分析sub_140576460函数。

sub_140576460函数将路径参数temp_path传入了sub_14049DA50。

首先，函数sub_14049DA50通过sub_140477C70对字符串进行了处理。然后，调用wstat64获取相应路径的文件状态，如果成功获取则保存到一个结构体中，否则返回0xffffffff。由于Temp目录下并未发现备份文件，导致获取状态失败，从而返回0xffffffff。

返回0xffffffff后，重新回到sub_140579b30函数中，程序跳出while循环到达如下位置，输出错误信息并跳转至sub_140572A70。

从sub_140572A70最终执行到sub_1400960C0，到达如下位置将vmware_vmx+0xb1ed90处的值赋给了rsi，即为0。

继续往下执行，将rsi中0值赋值到rax中，然后调用0x7ff8fab0c510处，即ntdll!LdrpDispatchUserCallTarget。

此处与静态下的过程有一点不同，静态下该处调用如下：

? 如果按照静态过程执行，应当到达sub_1407C7650,即如下位置：

在ntdll.dll被加载之前，该处数据依旧为上图所示地址：

? 后来在ntdll.dll中实施CFG（ControlFlow Guard）保护机制，将vmware_vmx+0x7c9668地址处数据进行了改写，从而执行到ntdll!LdrpDispatchUserCallTarget中。

在ntdll!LdrpDispatchUserCallTarget函数中，取r11+r10*8处的值赋值给r11时出现了问题，该地址为空，就造成了空指针引用，从而执行了int 29h，造成异常。然而，即使没有CFG机制，程序也会在执行“jmp rax”处崩溃，通过下图可以看出，CFG机制仅仅是在原本程序跳转指令前添加了一些检查。