Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

0
0
【漏洞分析】CVE-2017-0283:windows Uniscribe远程代码执行漏洞分析

2017-07-13 14:46:35

阅读:1347次
点赞(0)
收藏
来源: blogspot.com





【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

作者:myswsun





【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

译者:myswsun

预估稿费:130RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


0x00 前言

上个“补丁星期二”,修复了一个名为“USP10!MergeLigRecords中的Windows Uniscrible 字体处理堆破环”的RCE漏洞。多天后,谷歌Project Zero团队的Mateusz Jurczyk发布了一个带有PoC的报告。在那个Windows库中同时存在了8个漏洞中,我选了这个最严重的漏洞来分析。


0x01 重现

在Windows字体查看器中打开压缩包Poc.zip中的字体文件,显示"quick brown fox text" ,但是没有崩溃。我是在Windows 7 x64中测试:

1. 解压PoC

2. 在系统中安装signal_sigsegv_313372b5_210_42111ccffd2e10aba8b5e6ba45289ef3.ttf(或者包中任何其他的TTF)

3. 运行notepad

4. 选择格式->字体...>[字体] 4000 Tall 和 [脚本] Arabic

立即会崩溃:


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

调用堆栈:


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

0x02 PoC的分析

通常应该浏览PoC,并且试图在深入调试之前理解它的payload,通过了解数据的布局将节约大量时间。因此我在网上搜索了原始的TTF文件。我观察两个文件之间的不同,以便定位到恶意构造的字体属性。比较显示了一个常见的结构体。然而,使用一个自动化fuzzer,得到太多可疑的属性。这非常耗时,我不得不放弃。


0x03 分析官方补丁

提取和分析官方补丁是下一步该做的事。因此让我们看一下。

漏洞版本是1.626.7601.23688版本的usp10.dll,被补丁1.626.7601.23807代替。文件大小大约一致(788KB),使用BingDiff找到了733个函数。其中有个是崩溃调用堆栈中的一个。首先检查这些函数中的不同,因为补丁经常会在漏洞调用之前检查输入数据。第一个(USP10!MergeLigRecords)来自立即崩溃的上下文,它是一样的。下一个(USP10!LoadTTOArabicShapeTables)显示了修改。下图左边的是老的(漏洞),右边是新的(补丁)。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

我们能看见有漏洞的调用MergeLigRecords在一个循环中。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

在循环中,补丁只有一个重要的修改,是上图灰色的cmp-jnz代码块。这就是补丁吗?目前为止,分析有限,还无法确定(rsp+var_9C)的比较是什么意思,但是很明显,通过新增的代码块能比老版本判断更精确。

现在唯一的方式就是调试了。因此我们启动WinDbg,并附加到notepad进程。我们设置3个断点。一个是有漏洞的MergeLigRecords,一个在ttoGetTableInfo调用之前,还有个在其之后。ttoGetTableInfo调用是有趣的,因为它有两个结构体参数TTOOutput和TTOInput。灰色中if块检查TTOOutput的属性(rsp+var_9C)是否为4,如果不匹配退出循环。因此我们感兴趣的是ttoGetTableInfo中rsp+var_9C是否改变了并且和MergeLigRecords中的崩溃有什么关系。在F5和点击PoC之前,我们还需要定位补丁版本中的rsp+var_9C属性。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

我们看到,在老的LoadTTOArabicShapeTables中有个名为rsp+var_A4的引用(在下面的代码段中解析为@rsp+34)。

现在我们能观察我们的断点


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

在头两个中,var_A4的值是0004,没有改变。USP10!MergeLigRecords调用执行没有崩溃。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

在第3个中,var_A4通过ttoGetTableInfo调用改变了,从0004变为了0001,并且MergeLigRecords崩溃了。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

此时,我们得出结论,灰色的cmp-jnz块能阻止崩溃,因此我们找到了补丁。


0x04 0patch补丁

目前为止,我们合起来看,所有的内容都在上述灰色部分,下面是我制作的.0pp文件。


【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析

当把官方补丁转成0patch补丁时,我使用了之前文中描述的"jump condition piggy-backing"技术。很方便,官方补丁是jnz退出有问题的循环,我们的0patch也是这个位置。我将它放在原始jnz前面。由于缺少空格(jnz只有2个字节,我们需要5字节跳转到我们的补丁代码),我不得不将它放于ttoGetTableInfo调用之前,0patch Agent将使用5字节跳转代替。补丁的第一条指令是替换为原始的ttoGetTableInfo。接下来是来自官方补丁的检查。首先是var_A4和4比较以检查循环是否要继续,否则保存ttoGetTableInfo的结果的eax置为1,因此test eax, eax会设置跳转标志(zf=0),jnz将退出循环。

在使用0patch Builder编译了.0pp文件之后,补丁就可用了,PoC将不再崩溃。我们的团队测试了PoC.zip中的其他ttf文件,所有的都不会崩溃。然而,需要注意的是这个补丁只覆盖了在重现场景中的执行过程。LoadTTOArabicShapeTablesthere的比较中,有另一个jnz灰色块被添加到usp10.dll中,存在类似的循环。但是因为没有公开的PoC可以触发,在0patch中我们不会覆盖它。0patch的安全使用方式是覆盖测试完全的补丁。



【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析
【漏洞分析】CVE-2017-0283:Windows Uniscribe远程代码执行漏洞分析
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://0patch.blogspot.com/2017/07/0patching-quick-brown-fox-of-cve-2017.html

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles





Latest Images