Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

admin 2020年8月13日01:12:42评论323 views字数 2049阅读6分49秒阅读模式

研究员在日常的高级威胁监控中发现,疑似CVE-2020-0938漏洞的在野POC出现在VirusTotal上,我们在发现该POC的第一时间内便对安全社区进行了预警。

漏洞背景及在野POC

2020年4月,奇安信威胁情报中心红雨滴团队对微软通告的Windows Adobe Type 1漏洞CVE-2020-0938进行了相关通告。自此,红雨滴团队一直保持着对该漏洞的高度关注。近日,红雨滴团队在日常的高级威胁监控中发现,疑似CVE-2020-0938漏洞的在野POC出现在VirusTotal上,我们在发现该POC的第一时间内便对安全社区进行了预警。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

目前VT上仅有8家杀软能对样本进行查杀:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

而该漏洞最早是由奇安信代码安全卫士的柳本金及张之义发现,且Google在当时还发现了相关的在野利用:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

样本在2020年8月3号最早被上传,上传地为乌克兰:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

从其对应的路径名来看可以确定该样本是从相关的安全研究员机器上上传的,而且有俄语相关背景。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

通过文件名我们可以找到以下几个相关的文件,其中pfb和mmm文件为对应的POC相关文件。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

样本的构造时间为7月10日:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

该POC通过一定程度的修改,可触发导致系统崩溃:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

漏洞原理分析

通过bindiff可以很容易找到存在问题的函数:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

漏洞的主要问题出现在type 1字体的BlendDesignPosition字段中,相关adobe type 1 font的介绍如下所示:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

详细的内容可以通过官网下的pdf查看:

https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5004.AFM_Spec.pdf

这里可以看到BlendDesignPosition的介绍,其本身是一个数组。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

而在对应的问题函数SetBlendDsignPositions中可以看到实际用于数组处理的空间是栈上的局部变量v9,如下所示其大小为960,根据for内的代码可知,每个element的大小是60,也就是说SetBlendDsignPositions的size大小应该是16,但是注意看这里的代码for循环,是没有校验对应的index数的,也就是说我们可以一直往后越界读取内容。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

而有意思的是在循环中每获取一个element,就会调用函数GetOpenFixedArray,而函数GetOpenFixedArray中会对对应的element进行一次写操作,如下所示,这就导致我们可以复写修改对应堆栈上的内容,如栈上的返回地址。而这里MakeFixed中返回的数据也是可控的,即array中当前element的内容。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

因此这里POC直接构造以下的array,其大小为24,每个element中依次设置对应的标记字符,从000-111,反复三次。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

因此作为检测的话,可以扫描对应文件开头是否为~%!PS-AdobeFont-1.0: type 1字体,之后检测是否包含BlendDesignPosition,且该数组中的元组[]数量是否大于16即可。

如下所示进入到函数SetBlendDesignPositions,可以看到这里首先分配3f0大小的堆栈空间。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

此时对应的调用栈帧如下:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

之后进入到for循环并调用GetOpenFixedArray,此时数组第一个element地址如rcx所示,还在数据栈上,rdi则标记对应的计数器。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

如下所示函数调用完成之后,对应的element中被拷贝了8个字节的内容,其对应于BlendDesignPositions数组中第一个元素[0,0,0]

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

通过断点监控之后所有的相关拷贝地址,可以看到在第0x11次的时候已经超过了当前的函数栈帧,这里POC触发崩溃并没有通过尝试修改栈上的返回地址来实现,而是修改了栈上一个关键的指针,从而触发一次违例写入。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

引用该栈上关键指针的函数为循环之后的SetNumMasters。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

进入SetNumMasters经过一系列调用进入一个jmp rdx的跳转,此时的esp为ffffd001`2944d210

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

步入该jmp后此时引用了栈上rsp+40处的一个指针,而该指针就是之前通过POC修改的,其对应值为00010000407db780

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

我们可以看到在之前第13次循环的时候修改了对应这个位置的数据,该指针的前8位正好被我们的数据修改了。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

修改的完整数据如下,对应的BlendDesignPositions数据为[1,1,0]。

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

此时被修改的后的指针如下(fffff901407db780->00010000407db780):

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

最终触发崩溃:

Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析

参考链接

https://ti.qianxin.com/advisory/articles/type-1-font-handling-remote-code-execution-vulnerability/

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0938

本文来源于互联网

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2020年8月13日01:12:42
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Windows Type1字体处理远程代码执行漏洞 (CVE-2020-0938) 在野POC分析http://cn-sec.com/archives/85271.html

发表评论

匿名网友 填写信息