写在最前

如果你是信息安全爱好者，如果你想考一些证书来提升自己的能力，那么欢迎大家来我的 Discord 频道 Northern Bay。邀请链接在这里：

https://discord.gg/9XvvuFq9Wb

我拥有 OSCP，OSEP，OSWE，OSED，OSCE3，CRTO，CRTP，CRTE，PNPT，eCPPTv2，eCPTXv2，KLCP，eJPT 证书。

所以，我会提供任意证书备考过程中尽可能多的帮助，并分享学习和实践过程中的资源和心得，大家一起进步，一起 NB~

背景

最近看到了 Microsoft Office 的一个 0day，是在2022年11月份披露的关于 RTF 字体表处理逻辑上的 heap corruption. 披露原文在这里。

漏洞披露文件作者（@jduck - Joshua J. Drake）指出了通过对 heap corruption 的利用，黑客可以达到执行任意代码的目的。

这个高危漏洞的 CVSS 分数达到了 9.8（Critical），漏洞编号 CVE-2023-21716。

涉及版本：

Microsoft Office 365 (Insider Preview - 2211 Build 15831.20122 CTR)
Microsoft Office 2016 (Including Insider Slow - 1704 Build 8067.2032 CTR)
Microsoft Office 2013
Microsoft Office 2010
Microsoft Office 2007

我们将在如下版本上做测试。了解一下这个漏洞的基本原理。

在这里插入图片描述

CVE-2023-21716

漏洞概述

该漏洞是利用 Office Word 软件的 RTF Parser 在解析 RTF 字体表的时候，存在 heap corruption 的漏洞。如果 RTF 文件（元信息）中，\fonttbl 字段包含了过多数量的字体，那么就会造成 heap corruption，导致软件崩溃。合理的利用，可以达到代码执行的目的。

原理解析

根据作者公布的信息，漏洞存在于 Office 软件的 WWLIB.DLL 中。但是作者没有透露太多的信息，类似具体的方法名等。

接下来我们一步一步反推一下这个漏洞的出现位置，以及原理。

IDA 反编译 wwlib.dll

在这里插入图片描述

首先第一步，IDA 一下这个库，找到目标方法。

首先拿下这个库的 pdb 文件，resolve 他的 symbols，好在 IDA 中 reference。

打开 WORD，用 WinDBG hook。然后可以看到 wwlib 加载了。

在这里插入图片描述

.reload /f

下载所有模块的 pdb 文件，这会需要比较长的时间。

在这里插入图片描述

下载完成之后。使用 IDA 加载 wwlib.dll。

IDA 加载 wwlib.dll 的时候，需要关联很多的其他 dll。所有这些关联的库，都在如下文件夹：

C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16

最后，加载 wwlib.dll 的 PDB 文件。

寻找目标方法

首先我们先大致上了解一下 RTF 文件的格式。

我们可以到这里搜索 font。可以找到 rtf 文件字体相关的规范。RTF 就是用这些表格中定义的控制字符，来定义例如字体等信息。

在这里插入图片描述

我们可以看到这样一段文字。意思是就算是不用的字体，RTF Parser 都会将其包括进 font table，这种无限制，也是漏洞成因之一。

All fonts available to the RTF writer can be included in the font table, even if the document doesn’t use all the fonts.

在这里插入图片描述

可以看到 font 中包含 fontnum 属性。

在这里插入图片描述
我们用例子来看一下实际 RTF 文件的格式是什么样子。

我们创建一个 RTF 测试文件。

在这里插入图片描述

保存成 RTF 格式。

在这里插入图片描述

用 Notepad 打开。

可以看到 RTF 文件以 \rtf1 开头。我们的文件内容，也可以在下面看到。

在这里插入图片描述

往后找，可以找到 \fonttbl 控制字符。

在这里插入图片描述

我尝试将以下 \rtf1 和 \fonttbl 之间的内容删去，文件照常可以打开。

\adeflang1025\ansi\ansicpg1252\uc1\adeff31507\deff0\stshfdbch31506\stshfloch31506\stshfhich31506\stshfbi31507\deflang1033\deflangfe1033\themelang1033\themelangfe0\themelangcs0

在这里插入图片描述

我们将 \fonttbl 中的值取出来。这些值是用 {} 括号包裹的控制字符，猜想每一对括号代表一种字体。我将他们复制到另一个地方，方便后续对照。下图红框种的，就是字体 id。

在这里插入图片描述

根据作者的透露，目标代码的指令如下：

0d6cf0b6 0fbf0e          movsx   ecx,word ptr [esi]         ; load base idx
0d6cf0b9 0fbf5602        movsx   edx,word ptr [esi+2]       ; load font idx
0d6cf0bd 8d1451          lea     edx,[ecx+edx*2]            ; multiply by ~3
0d6cf0c0 668b08          mov     cx,word ptr [eax]          ; load the codepage value
0d6cf0c3 66894c5604      mov     word ptr [esi+edx*2+4],cx  ; write the code page

所以我使用 movsx ecx,word ptr [esi] 作为目标字符串开始搜索哪些方法出现了这个字符串。

在这里插入图片描述
最后找到了目标方法 FSearchFtcmap。

在这里插入图片描述

也在 FSearchFtcmap 方法中找到了目标指令。

在这里插入图片描述

验证目标方法

打开 word，WinDBG hook，然后在方法上打上断点。先验证一下 Word 打开 RTF 文件会走到这个方法。

在这里插入图片描述

在 FSearchFtcmap 方法上打上断点。

在这里插入图片描述

让 Word 继续运行。然后在 Word 中打开 Test rtf.rtf 文件。

触发断点。

在这里插入图片描述

所以该方法就是我们要找的目标方法。

行为分析

我们看一下 IDA 里面的目标指令和方法起始位置的偏移量，直接把断点打到目标指令上。方便后续调试。这个偏移量是 0x165。

我们直接把断点打在 wwlib!FSearchFtcmap+0x165 上。

bp wwlib!FSearchFtcmap+0x165

在这里插入图片描述

输入 g 继续执行的时候，直接触发了新添加的断点。

在这里插入图片描述

像个循环，一直执行。

其实整个 FSearchFtcmap 方法会被调用很多次。

在这里插入图片描述

我们可以看到，下图中 esi 中的值，其实是一个 index，我猜想一共多少个字体文件，esi 就会增加到这个值。

在这里插入图片描述

我看了一下，一共调用了91次。所以再次打开之前的 Test ttf 文件，将 fonttbl 复制出来看一下是否包含了 91 个font 类别。

在这里插入图片描述

一共 91 行。猜想正确。

在这里插入图片描述

这些是 font id。我们可以参照之前打开的 rtf 文件，看一下这些 font id。

在这里插入图片描述

将他们转换成 16 进制。

在这里插入图片描述

与 esi 中的值做比对。发现 font id 是存储在 esi 中。

在这里插入图片描述

我们看危险代码执行之后，esi 中的值会递增。

在这里插入图片描述

这是所有问题的起源。
在这里插入图片描述

而由于这里使用了 movsx 命令（关于这个命令的文档看这里），32位寄存器最高位会被赋予源地址中值的符号位。如果源值的符号位为 f，那么目标地址最终包含的值的高 16 位均为 f。这是 Access Violation 的根源。

高 16 位都填满了 f，那么在做地址计算的过程中，就会触及不可访问的地址，导致最终的 heap corruption。

验证漏洞

漏洞验证阶段，我发现 WinDBG 无法如作者所说抛出异常。时间关系先发布，后面会继续回来测试，学习 heap corruption 的后利用姿势。

初步总结

目前为止，我们找到了 wwlib 库中的问题方法，初步了解了 RTF 格式以及控制字符。接着我们对 wwlib 中的 FSearchFtcmap 方法进行了行为分析，知道了 font id 是存放在 esi 中，切 esi 作为循环加载字体的 index，index 值将会使用 movsx 指令分别加载到 ecx 和 edx 中。

由于时间原因，还没有对后续做更加深入的测试。之后会找时间继续 heap corruption 的学习，以及最终该如何利用这个漏洞达到代码执行的目的。

为了安全，微软建议不要打开来历不明的文件，即使不是 RTF 后缀的文件也不要随意打开。

未完待续…

参考链接

https://www.felixcloutier.com/x86/movsx:movsxd
https://stackoverflow.com/questions/26124620/why-does-msvc-emit-a-useless-movsx-before-performing-this-bit-test
https://www.oreilly.com/library/view/learning-malware-analysis/9781788392501/88906546-5ffc-4341-a478-cefb23ea7547.xhtml
http://www.trlevelmanager.eu/plugin_sdk_help/first_steps_asm.htm
https://qoop.org/publications/cve-2023-21716-rtf-fonttbl.md
https://stackoverflow.com/questions/16985554/rtf-file-format-changes
https://www.biblioscape.com/rtf15_spec.htm
https://latex2rtf.sourceforge.net/RTF-Spec-1.2.pdf
https://www.picussecurity.com/resource/blog/cve-2023-21716-microsoft-word-remote-code-execution-exploit-explained
https://www.cyberark.com/resources/threat-research-blog/a-modern-exploration-of-windows-memory-corruption-exploits-part-i-stack-overflows
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2023-21716