机窝安全--fuzz文件格式

继续有关模糊测试的系列，本节我将分享如何在窗口上找到要模糊化的攻击面。在处理大量文件格式的Windows上，学习和模糊这些文件格式是当今在Windows上查找错误的常用方法。方法和模糊与我在上一节中提到的Irfanview中查找错误完全相同。

[出自:jiwo.org]

也许有很多人想知道如何找到攻击面？当你研究的东西足够长，足够深，以至于你看到攻击它的可能方向时，它就是这样。对于大多数初学者来说，这种情况听起来很难，因为不是每个人都那么优秀和优秀。但有趣的是，有很多优秀的研究人员愿意将他们研究的所有内容和他们发现的错误分享给社区。Google Project Zero （P0） [1] 就是一个例子，我看到并跟踪了上面发布的 bug（包括很久以前的 bug）。从那里我了解了错误类型，表面攻击，经常在不同平台上导致错误的组件等。或者只是每月一次跟踪来自Microsoft [2]的补丁，看看错误是否被修补。什么有趣，适合我的模糊方向与否。

介绍

回到讨论Windows上的模糊文件格式，正如我们所知，在Windows上有很多DLL，每个DLL都有一个单独的任务。对我来说，暂时，我将专注于处理文件格式的DLL。一些常见的文件格式，如媒体：音频，视频，图像,...或一些其他文件格式，如XML，XPS，PDF，注册表,...这些 DLL 将导出到 API，供开发人员用于构建 Windows 应用程序，Windows 内置组件也使用这些 API。

微软本身为我们提供了MSDN [3]，这是一个供我们阅读和学习使用这些API的存储库。不仅有API文档，微软也慷慨地给了我们很多示例代码。我通常指的是Microsoft GitHub存储库[4]。它在构建工具以模糊化Windows上的文件格式方面有很大帮助。

微软字体子集

Windows字体是一种我发现非常多样化的文件格式，因为内核模式计数用户模式具有字体处理组件。P0公开谈论窗口的模糊字体[5][6]，它们都非常清晰和有质量。在 P0 发现的与字体相关的错误中，我关注了 fontsub.dll 库。

直到这个库的P0公共错误出现之前，以前还没有人尝试过模糊进入fontsub.dll库。

Microsoft Font Subsetting DLL（fontsub.dll）是用于子集TTF字体的默认Windows帮助程序库;即根据嵌入字体的文档中使用的特定字形将字体转换为更紧凑的版本。它由Windows GDI和Direct2D使用。

该 DLL 导出两个 API 函数：CreateFontPackage [7] 和 MergeFontPackage [8]。

无符号长创建字体包（

const unsigned char *puchSrcBuffer，

const unsigned long ulSrcBufferSize，

unsigned char **ppuchFontPackageBuffer，

无符号长 *pulFontPackageBufferSize，

无符号长 *pulBytes写，

const unsigned short usFlag，

const unsigned short usTTCIndex，

const unsigned short usSubsetFormat，

const unsigned short usSubsetLanguage，

const unsigned short usSubsetPlatform，

const unsigned short usSubsetEncoding，

const unsigned short *pusSubsetKeepList，

const unsigned short usSubsetListCount，

CFP_ALLOCPROC lpfnAllocate，

CFP_REALLOCPROC lpfnReAllocate，

CFP_FREEPROC lpfnFree，

void *lpvReserved

);

无符号长合并字体包（

const unsigned char *puchMergeFontBuffer，

const unsigned long ulMergeFontBufferSize，

const unsigned char *puchFontPackageBuffer，

const unsigned long ulFontPackageBufferSize，

无符号字符 **ppuchDestBuffer，

无符号长 *脉冲最大增大，

无符号长 *pulBytes写，

const unsigned short usMode，

CFP_ALLOCPROC lpfnAllocate，

CFP_REALLOCPROC lpfnReAllocate，

CFP_FREEPROC lpfnFree，

void *lpvReserved

);

P0还发布了他们构建的工具[9]，它非常好，涵盖了传递给这两个函数的所有参数。我用那个安全带来模糊。

除了 Harness 之外，P0 还有一个支持 TTF/OTF [10] mutate 文件的公共工具，我认为这是帮助 P0 找到许多此类字体 bug 的关键工具。

基于这些，我开始寻找和创建copus：

1.来自P0的语料库公开，以前发布过的错误+在互联网上下载

2. 根据 P0 工具改变这些语料库

3. 使用 winafl-cmin 减少语料库的数量

4. 检查覆盖范围

5. 返回步骤 2

我一遍又一遍地做这个任务，直到我用fontsub.dll达到的覆盖率如下：

通过测试用例，我可以在DLL fontsub上改变53.22%.dll，CreateFontPackage的可变率为81.08%，MergeFontPackage的变异率为76.40%。我认为这足以开始模糊。

我使用Winafl与1个主人和7个奴隶一起运行，几个小时后，我开始看到第一次崩溃。几天后，我回去开始检查那些崩溃。

其中大多数是堆栈溢出错误（0xc00000fd）：

P0 之前报告了 2 个错误，微软没有修复 [11] [12]。

还有一个崩溃，在我看来，这与P0早些时候报告的微软已经修复的错误非常相似[13]。

我报告，微软已经同意解决这个问题。似乎这是一个带有Microsoft之前修复过的错误的变体。该错误在T4/ 2020补丁（CVE-2020-0687）中修复，这是我写的这个错误的根本原因分析，每个人都可以阅读[14]，（在文章中你应该只关注这个错误分析，影响不是我写的，当然，有这样的错误，其实不能有完全的利用）。

根据谷歌时间线，该错误修复已于2019年8月修复，但我确实对其进行了模糊处理，并且该错误一直持续到2020年1月（我向Microsoft报告的那一刻）。

我对微软没有完全修复这个错误并不感到惊讶，但是这个P0公共项目还没有被任何人用来查找错误。

结论

这个错误并不难找到，一切都在你面前可用，但没有人跳进去。您可以看到，我在上一篇文章中清楚地展示了我展示的步骤，所有这些基础知识都不必使用反向来编写线束。微软的文档非常完整，请阅读它，学习它，并尝试一下。如果我只是停止阅读博客，那么我认为它不会带来太多结果。

当窗口的模糊文件格式越来越少出现时出错。因为这种方式是相当多的用户，它需要你花很多时间研究新的表面攻击，没有研究过的文件格式，以便能够发现错误。

以下博客将讨论一个文件格式错误，微软在Windows Insider Preview Bounty中奖励了我最大的赏金。也许我会在微软的T6 / 2020补丁发布或更长时间后发布它。

[1] https://googleprojectzero.blogspot.com/

[2] https://portal.msrc.microsoft.com/en-us/security-guidance/acknowledgments

[3] https://docs.microsoft.com/en-us/

[4] https://github.com/microsoft/Windows-classic-samples

[5] https://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-font-fuzzing-1_27.html

[6] https://googleprojectzero.blogspot.com/2016/07/a-year-of-windows-kernel-font-fuzzing-2.html