CVE-2021-1665分析

译文声明

本文原作者Hardik Shah,原文来源https://www.mcafee.com/blogs/other-blogs/mcafee-labs/analyzing-cve-2021-1665-remote-code-execution-vulnerability-in-windows-gdi/

介绍

CVE-2021-1665是Windows GDI+ 中的一个远程代码执行漏洞,GDI+即Microsoft Windows 图形设备接口+,各种应用程序使用GDI+在视频显示器和打印机上使用不同的图形功能,Windows应用程序不直接访问设备驱动程序等图形硬件,但它们与GDI交互,然后GDI又与设备驱动程序交互,这样Windows应用程序就有了一个抽象层和一组供每个人使用的通用API。

GDI+因为格式复杂,因此有各种已知的漏洞历史。我们在McAfee上不断地fuzz各种开源和闭源软件,包括Windows GDI+,在过去几年中,我们向Microsoft报告了包括GDI在内的各种Windows组件的各种问题,并收到了它们的CVE。

本文中我们详细分析了我们使用WinAFL发现的一个此类漏洞:CVE-2021-1665 – GDI+ 远程代码执行漏洞,该问题已于 2021年1月作为 Microsoft 补丁的一部分得到修复。

winafl介绍

WinAFL是一个流行的Linux AFL fuzzer的Windows端口,由谷歌Zero项目的Ivan Fratric维护,WinAFL使用DynamoRIO进行动态二进制检测,它需要一个线束程序,线束是一个简单的程序,它调用我们想要fuzz的API。

WinAFL已经提供了一个简单的线束,我们可以在代码中启用“Image->GetThumbnailImage”代码,该段代码做了注释,以下是Fuzz GDI + Image和GetThumbnailimage API的线束代码:

如您所见,这一段代码是从提供的输入文件创建一个新的图像对象,然后调用另一个函数来生成缩略图图像,这是一个优异的攻击向量,使用缩略图的各种Windows应用程序都可能会受到影响,此外这只需要很少的用户交互,因此使用GDI+并调用GetThumbnailImage API的软件很脆弱。

语料库收集

良好的语料库会为fuzz提供一个好的基础,除了从其他软件和公共EMF文件中获取测试语料库之外,我们还可以使用Google或GitHub获取测试语料库,这些文件是针对其他漏洞发布的,我们已经生成了一些测试文件,我们通过对Microsoft网站上提供的示例代码进行修改生成一些测试文件,下面的示例使用一个带有EMFplusDrawString和其他记录的EMF文件:

参考

最小化语料库

在我们收集了初始语料库文件后,我们需要将其最小化,我们可以使用名为winafl-cmin.py的实用程序将其最小化,如下所示:

winafl-cmin.py -D D:\\work\\winafl\\DynamoRIO\\bin32 -t 10000 -i inCorpus -o minCorpus -covtype edge -coverage_module gdiplus.dll -target_module gdiplus_hardik.exe -target_method fuzzMe -nargs 2 — gdiplus_hardik.exe @@

Winafl如何工作

WinAFL使用内存模糊的概念,我们需要向WinAFL提供一个函数名,它将在函数开始时保存程序状态,并从语料库中取出一个输入文件,使其变异,并将其提供给函数。

它将监控任何新的代码路径或崩溃,如果它找到了一个新的代码路径,它将把新文件视为一个有趣的测试用例,并将其添加到队列中进行进一步的变异,如果发现任何崩溃,它将保存崩溃文件到的崩溃文件夹中。

以下图片显示fuzz流程:

使用Winafl进行fuzzing

我们编译了harness程序,收集并最小化了语料库,我们就可以运行这个命令来用WinAFL模糊我们的程序:

afl-fuzz.exe -i minCorpus -o out -D D:\work\winafl\DynamoRIO\bin32 -t 20000 —coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module gdiplus_hardik.exe -target_offset 0x16e0 -nargs 2 — gdiplus_hardik.exe @@

结果

我们发现了一些崩溃并对这些崩溃作了分类,我们在“gdiplus!”BuiltLine::GetBaselineOffset "中发现了一个崩溃,它的调用堆栈如下所示:

如上图所示,程序在试图从edx+8指向的内存地址读取数据时崩溃,我们可以看到它的寄存器ebx, ecx和edx包含c0c0c0c0,这意味着二进制文件启用了页堆,我们还可以看到c0c0c0c0被作为参数传递给“gdiplus!”FullTextImager: :RenderLine”函数。

根据补丁寻找根本原因

要找出根本原因,我们可以使用补丁差异——即我们可以使用IDA BinDiff插件来确定补丁对文件做了哪些更改,幸运的话我们可以通过查看更改的代码轻松地找到根本原因,所以我们可以生成gdiplus.dll补丁和未补丁版本的IDB文件,然后运行IDA BinDiff插件来查看更改。

我们可以看到在补丁文件中添加了一个新函数,这个函数好像是BuiltLine对象的析构函数:

我们还可以看到,有一些函数的相似度小于1,其中一个函数是FullTextImager::BuildAllLines,如下所示:

现在,为了确认这个函数是否真的是被修补的那个,我们可以在windbg中运行我们的测试程序和POC,并在这个函数上设置断点,我们可以看到命中了这个断点,程序不再崩溃了:

下一步我们需要确定这个函数中有什么变化修复了这个漏洞,我们可以检查一下这个函数的流程图,我们可以看到如下内容,因为有太多的变化来识别漏洞,需要看看差异:

左边显示未修补的dll,右边显示修补过的dll:

1、绿色表示补丁块和未补丁块相同。

2、黄色块表示未打补丁和打补丁的dll之间有一些不同。

3、红色块显示dll中的差异。

如果我们放大黄色方块,我们可以看到下面的内容:

我们可以注意到一些变化,修补的DLL中删除了几个块,所以补丁差异将不足以识别这个问题的根本原因,但这为使用其他方法(如windbg)进行调试查找何处以及查找什么提供了有价值的提示,我们可以从上面的混合输出中找到一些观察结果:

1、在未修补的DLL中,如果我们仔细检查,我们可以看到一个对“GetuntrimmedCharacterCount”函数的调用,稍后还有另一个对“SetSpan::SpanVector”函数的调用。

2、在这个补丁DLL中,我们可以看到有一个对“GetuntrimmedCharacterCount”的调用,其中EAX寄存器中存储的返回值被检查,如果它是0,那么控制跳转到另一个位置- BuiltLine对象的析构函数,这是在补丁DLL中新添加的代码:

wKg0C2DdcnqAEbrSAAA1wBsnzns547.png

所以我们可以假设这是漏洞固定的地方,现在我们需要弄清楚以下几点:

1、为什么我们的程序和提供的PoC文件崩溃了?

2、文件中的哪个字段导致了这个崩溃?

3、该字段的值是多少?

4、程序中的哪些条件导致这个崩溃?

5、这个崩溃如何修复?

EMF文件格式

EMF也被称为增强元文件格式,它用于独立存储图形图像设备,EMF文件由不同长度的记录组成,它可以包含各种图形对象的定义、绘图命令和其他图形属性。

资料来源:MS EMF文档。

通常EMF文件包括以下记录:

1、EMF标题,包含关于EMF结构的信息。

2、EMF记录,可以是各种可变长度的记录,包含有关图形属性、绘制顺序等信息。

3、EMF EOF记录,EMF文件中的最后一条记录。

EMF文件格式的详细规格可在Microsoft网站上看到

在EMF文件中定位漏洞记录

通常,EMF中的大多数问题都是由于格式错误或损坏的记录造成的,我们需要找出什么记录类型导致了这次崩溃,我们查看调用堆栈可以看到以下内容:

我们可以注意到对“gdiplus!”GdipPlayMetafileRecordCallback”函数的调用:

在这个函数上设置断点并检查参数可以看到:

我们可以看到EDX寄存器包含一些内存地址,我们可以看到这个函数的参数是00x00401c、0x00000000和0x00000044。此外检查EDX寄存器指向的位置时可以看到以下内容:

检查我们的POC EMF文件可以看到这个数据属于来自偏移量ox15c的文件:

通过查看EMF规范并手动解析记录,我们可以很容易地发现这是一个“EmfPlusDrawString”记录,其格式如下所示:

在我们的例子中:

Record Type = 0x401c EmfPlusDrawString record

Flags = 0x0000

Size = 0x50

Data size = 0x44

Brushid = 0x02

Format id = 0x01

Length = 0x14

Layoutrect = 00 00 00 00 00 00 00 00 FC FF C7 42 00 00 80 FF

String data =

现在我们找到了可能导致崩溃的记录,之后要做的是找出为什么我们的程序会崩溃的原因,我们调试和检查代码可以看到控件会到达“gdiplus!FullTextImager::BuildAllLines”函数,当我们反编译这段代码时,我们可以看到如下内容:

下面是函数调用的层次结构:

执行流程总结

1、“Builtline::BuildAllLines”函数中有一个while循环,程序在该函数中分配0x60字节内存,然后调用Builtline:: Builtline函数。

2、“Builtline:: Builtline”函数将数据移动到新分配的内存中,然后调用“Builtline:: GetUntrimmedCharacterCount”函数。

3、将“BuiltLine::GetUntrimmedCharacterCount”的返回值添加到循环计数器ECX寄存器中,这个过程不断重复,直到循环计数器ECX<ECX寄存器的string length,这里是0x14。

4、循环从0开始,0x13终止,或者当“GetUntrimmedCharacterCount”的返回值为0时终止。

5、脆弱的DLL中程序不会因为循环计数器增加而终止,这里“BuiltLine::GetUntrimmedCharacterCount”返回0,它被添加到循环计数器ECX中,并不增加ECX值,它分配0x60字节的内存并创建另一行,破坏随后导致程序崩溃的数据,循环执行21次,而不是20次。

细节

1.“Builtline::BuildAllLines”分配0x60或96字节的内存,调试器中它看起来如下:

2.然后调用“BuiltLine::BuiltLine”函数,并将数据移动到新分配的内存中:

3.这发生在side a while循环中,并且有一个函数调用“BuiltLine::GetUntrimmedCharacterCount”。

4.“BuiltLine::GetUntrimmedCharacterCount”的返回值存储在0x12ff2ec位置,该值为1,如下图所示:

5.该值添加到ECX中:

6.然后有一个检查判断ECX<EAX,如果为true,它将继续循环,反之它将跳转到另一个位置:

7.现在在存在漏洞的版本中如果“BuiltLine::GetUntrimmedCharacterCount”的返回值为0,则循环不存在,这个0将被添加到ECX中,这意味着ECX不会增加,因此循环将使用0x13的“ECX”值再执行1次,这将导致循环执行21次,而不是20次,这就是问题的根源。

此外经过一些调试,我们可以弄清楚为什么EAX寄存器包含14,它从POC文件中读取了偏移量:0x174:

如果我们回忆一下,这是EmfPlusDrawString记录,0x14是我们之前提到的长度,之后程序到达“FullTextImager::Render”函数会破坏EAX的值,因为它读取未使用的内存:

这将作为参数传递给“FullTextImager::RenderLine”函数:

然后程序将在访问该位置时崩溃:

当访问一个无效的内存位置和处理字符串数据字段时,程序在处理EMF文件中的EmfPlusDrawString记录时崩溃了,主要是该程序没有验证“gdiplus!BuiltLine::GetUntrimmedCharacterCount”函数的返回值,导致采取不同的程序路径,损坏寄存器和各种内存值,最终导致崩溃。

如何解决问题

正如我们通过上面的补丁差异发现的那样,补丁添加了一个检查,它决定了“gdiplus!”BuiltLine: GetUntrimmedCharacterCount”函数的返回值。

如果返回值为0,则程序xor ebx,ebx后的EBX寄存器包含计数器并跳转到一个位置,该位置调用Builtline对象的析构函数:

下面是阻止这个问题的析构函数:

结论

GDI+是一个非常常用的Windows组件,像这个的漏洞可能会影响全球数十亿个系统,我们建议用户适当的更新并保持其Windows部署的最新状态。

我们在McAfee上正在持续fuzz各种开源和封闭的源库,并与供应商合作解决这些问题,通过负责地披露这些问题,给他们适当的时间来修复问题,并根据需要发布更新。

我们感谢Microsoft与我们一起修复了这个问题并发布了更新。

免责声明:文章内容不代表本站立场,本站不对其内容的真实性、完整性、准确性给予任何担保、暗示和承诺,仅供读者参考,文章版权归原作者所有。如本文内容影响到您的合法权益(内容、图片等),请及时联系本站,我们会及时删除处理。查看原文

为您推荐