介绍：

和我们一起微调的人都知道可以不重启电脑甚至不重启动正在运行的应用仅仅通过微调就可以修补对应的漏洞。换句话说，微调不会打断用户及服务。

现在让我们更进一步。你知道在IT环境中哪个组件是最不愿意重启的么？你猜对了：管理程序。特别是有几十或几百个关键虚机正在运行，这些虚机在管理程序被打补丁时都需要停止或挂起，直到补丁打完后才可以回到线上。而且，一旦补丁没有打成功...你能想象那场景，会相当感人。

当下一个心脏滴血，破壳或客户机逃逸漏洞出现，毫无疑问全球的管理程序要被大规模修补并且重启。那时重管理程序供应商到企业CIO,管理员到终端用户，相当多的人会经历各种不快。

几周前，Comsecuris公布了VMware Workstation中三个漏洞的详细报告，该漏洞允许恶意客户机导致主机上运行的管理程序（vmware-vmx.exe）内存损坏（我们都知道这会导致什么）。 Nico和Ralf巧妙地在客户机中修补了VMware图形相关DLL的客户机组件，这个补丁修补了对应Dll发送畸形的数据结构给管理程序而管理程序由于缺少检查而崩溃的问题。 （有趣的是，管理程序的调试版本却有相关assert断言检查，而这些对于漏洞分析和打补丁都非常有帮助。）

Comsecuris提出的三个漏洞已经由VMware修补，两个在Workstation 12.5.5中，另一个在Workstation 12.5.7中。 我们决定为12.5.7中修补的编写一个微补丁，以显示如何在不停止运行虚拟机的情况下修补管理程序。

PoC复现：

我们在运行VMware Workstation 12.5.5的64位Windows 10机器上复现了Comsecuris的“dcl_resource”PoC。 （有趣的事实：你可以在一个VMware Workstation里运行另一个VMware Workstation。）

对于那些想把玩这个PoC的人：安装Python for Windows和Visual C ++ 2015 Redistributable，将PoC文件放在一个文件夹中，启动exec_poc.py并等待虚拟机崩溃。 如果它没有崩溃（我们起初也没有崩溃），请确保您的虚拟机的硬件兼容性设置为“Workstation 12.x”或其他合理的，否则Poc所依赖的DirectX 10将不被支持。

漏洞分析：

一旦我们使其生效，PoC使运行在虚拟机的vmware-vmx.exe崩溃。 我们附加了一个调试器后发现，即使Comsecuris的报告非常详细，但也很难将我们的崩溃上下文与他们的分析相匹配，因为在那里有许多令人费解的代码。

因此，使用Comsecuris报告的提示，使用管理程序的调试版本，我们用vmware-vmx-debug.exe替换了vmware-vmx.exe，并重复了这个过程。 结果是这样的：

弹出的断言消息揭示了断言的源代码行。奇怪的是，在release版本中未被捕获的漏洞被断言阻止了，不过，它看起来很有希望， 所以我们搜索了反汇编后的shaderTransSM4.c中的字符串和行号为1956的十六进制数据，并找到了匹配关系（左下角的橙色块）：=========这句有点不顺，请参考原文：An assert message popped up revealing the assert's source code line. It seemed odd that an exploit that apparently hasn't been envisioned in the release version would be stopped by an assert, but hey, it looked really promising.  So we searched the disassembly for shaderTransSM4.c string and the hex equivalent of 1856 (the line number) - 740h. And found a match (lower left orange block):）

当向上滚动代码图时，我们得到了一个源于case 的整个断言链case子句88（右上角的橙色块）：

接下来，我们反汇编了发行版的vmware-vmx.exe（崩溃的），并在那里找到了一个匹配的case 88语句，但没有发现类似于调试版本中的assert链的检查。

然后，我们使用vmware-vmx.exe的加固后的12.5.7版本进行了对比，并发现与case 88语句相同的级联检查。 因此，VMware开发人员明显将调试版本的assert语句移到了release版本。 下面的图片显示了修补case 88代码分支在左边，对应脆弱的版本在右边。

指向级联中的最后一个块（深红色），指向默认的绿色分支（右边脆弱版本展示了）或者指向左边红色块（该块处理rbp+1a8h指向内容大于等于80H时候的异常---也就是左下角那个块）。 那个暗红色的区域阻止了PoC。 重读原始报告也印证了我们的结论。 它表示，所披露的漏洞“是用与调试版本完全相同的代码修复的”。

写一个微补丁:

有了这些信息，我们就可以创建一个微补丁。ecx上，我们选择在灰色框中的最后一个jmp指令之前设置一个指令的补丁位置：mov [r12 + 1Ch]，ecx。理论上我们可以在jmp之后注入它，但是0patch Agent目前不支持修补相对的jmp指令（将来会）。在补丁中，我们实现了与上面暗红色块等效的缓冲区溢出检。我们只需要将rbp + 1A8h替换为在对应上下文中工作：r12 + 50h。如果检测到尝试的溢出，我们的补丁代码会调用“利用尝试被阻止”对话框，将rcx设置为字符串“00patch: Exploit Blocked for CVE-2017-4924!”，并跳转到原始代码中的错误处理程序将我们的自定义消息字符串写到vmware.log并终止格式错误的数据结构的处理。

所以，这个补丁的好处不仅在于不打乱正在运行的虚拟机而修复漏洞，还会在VMware Workstation日志中记录一个错误以供后续检查。

下面是最后的0pp文件，我们的微补丁源代码。

MODULE_PATH "..\AffectedModules\vmware-vmx.exe-12.5.5.17738\vmware-vmx.exe"

PATCH_ID 291

PATCH_FORMAT_VER 2

VULN_ID 2971

PLATFORM win64

patchlet_start

 PATCHLET_ID 1

 PATCHLET_TYPE 2

 PATCHLET_OFFSET 0x0021223f

 PIT vmware-vmx.exe!0x002122b5

 code_start

  cmp dword[r12+50h], 80h ; r12+50h equals rbp+50h in 12.5.5. debug

                          ; and rbp+1A8h in 12.5.7. release

  jb skip

  call PIT_ExploitBlocked

  call arg1                   ; push string

  db "0patch: Exploit Blocked for CVE-2017-4924!",0Ah,0;

 arg1:

  pop rcx

  jmp PIT_0x002122b5          ;jump to the error handler @ loc_1402122A3+12

 skip:

 code_end

patchlet_end

Going Live

（视频是youtube上的，后续我将其放到国内可以访问的一个地址吧）  转到youku上面视频效果掺不忍睹 4d9K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4k6Q4x3X3g2&6L8%4g2C8N6g2)9J5k6h3y4G2L8g2)9J5c8Y4k6Q4y4h3k6K6K9r3!0%4i4K6u0r3K9h3c8Q4y4h3k6j5e0i4A6q4y4p5#2*7d9i4W2y4K9V1@1H3e0f1q4Q4x3@1c8Q4x3@1c8Q4x3X3g2Z5N6r3#2D9i4K6y4r3M7%4m8E0i4K6y4p5j5e0u0Z5x3$3A6Q4x3X3f1^5y4o6t1^5y4K6M7H3i4K6u0W2x3K6b7I4y4U0l9#2z5g2)9J5k6e0p5`.  我下面提供个youtube上面720P下载的附件吧。

看到我们的实际操作的微补丁视频。 正如您在演示崩溃后所看到的，我们在虚拟机正在运行时修补vmware-vmx.exe，PoC被阻止了。

结束语

我们想要演示未来如何给虚拟机管理程序中的漏洞打补丁的方式：即时，不会干扰正在运行的虚拟机，严格针对特定的漏洞（而不是替换数以兆字节的代码），并且立刻能取消有缺陷的补丁。虽然VMware Workstation不太可能宿主停止或挂起后代价高昂的关键虚机，但同样的漏洞也会影响ESXi，而ESXi正在全球运行着大量的关键机器。不幸的是，我们目前无法对ESXi进行微补丁，但是如果有兴趣，没有理由不能这样做。

您可能已经注意到，我们的补丁只能解决由Comsecuris的PoC演示的特定缺陷，而调试管理程序版本具有一组断言语句，每个语句都可能在不同的无效值上触发。因此，漏洞利用作者可能可以通过这些断言语句并编写PoC来解决我们的微补丁还没有解决的其他case分支。尽管如此，我们不是要在这里创建新的PoC，而是证明我们可以为系统缺陷做微补丁修复。如果VMware使用微补丁方式，他们可以很容易地将缺陷做多次微补丁修复（或甚至只进行一次比平常大点的微补丁修复）。

我们希望能够让所有产品开发团队（他们知道补丁对其是高昂的）了解到微补丁的概念，并且想要做一些事情来推广。

最后，感谢Comsecuris的Nico Golde的可以工作的PoC提供的有用提示，和相关补丁的有用想法。

如果您已经安装了0patch代理程序（它仍然是免费的！），那么所有的魔力已经存在：这个微补丁已经在您的计算机上，并且在您启动VMware Workstation 12.5.5时会自动应用。如果你想有一些其他版本的VMware Workstation相同的修补程序请联系我们。

@0patch