翻译：啦咔呢
预估稿费：170RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
传送门
【技术分享】0patch一个0day漏洞：Windows gdi32.dll内存披露（CVE-2017-0038）
前言
自从上一篇文章发表已经过去一周了，所以在微软每周二定期更新补丁前的这段空隙里，似乎是时候发布另一个0patch了。这一周过得很有趣，因为我们0patch平台（开放测试版正在进行中）吸引了大量新用户提供了许多有用的反馈。
CVE-2017-0037：IE 11类型混淆漏洞
这一次我发布的是有关IE11的补丁，它可以保护一个比之前更严重的漏洞，这个漏洞据说可能允许远程代码执行。我再次根据Google Project Zero提供的bug报告进行分析，该报告会在90天后自动解除限制。这一次是Ivan Fratric 获得荣誉。
PoC（可以从Ivan报告的顶部提取）是一个简短的HTML文件，在IE11中打开时，JavaScript自动地重新格式化一张HTML表的StyleSheet属性导致了类型混淆，并以崩溃的方式结束。在开启 Application Verifier 的情况下检查崩溃现场并附加上 WinDbg，我得到了相同的结果如下：
(430.1a4c): Access violation - code c0000005 (!!! second chance !!!)
MSHTML!Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement+0xa4:
000007fe`ddeeba17 48833800 cmp qword ptr [rax],0 ds:00000078`00000070=????????????????我执行！heap -p -a @rbp来获取损坏对象创建的调用堆栈。它表明非法rax地址源于Array <int> :: Create
没有迹象表明这是典型的内存损坏漏洞，如缓冲区溢出漏洞，或与崩溃直接有关的use-after-free漏洞，而这种崩溃大多可以用几乎标准的方式去分析和修补（见我们以前的博客文章）。因此，我总结出，为了解决这个漏洞，一个较不确定且更详细的分析是很必要的。而我们所需要的是一组从PoC衍生的探针，以便将正确的执行流程与非法的执行流程分开。然后这些探针可以在WinDbg中被跟踪并与 trace-dump对照。进而我发现了：
1、 boom()函数调用可以导致仅由一些事件触发的崩溃，而这些事件都是从页面加载中分离出来的，如点击或定时器事件。
2、除了“aaaaaaaaaaaaaaa”，mediaText可以设置为合法的值，如print，handheld，projection等，浏览器仍然会崩溃
3、静态定义的媒体（在css 定义内）不会导致崩溃。
附加到探针后我跟踪了所述的Array <int>到崩溃的生命周期，以及在设置了mediaText和th1.align的各种情况之间的差异。在我有限的时间内，我只能比较所述探针跟踪到执行流的几个组合，但最终也没有完全理解非法解析行为到底发生在哪里。时间上不占优势，所以我选择了一个更简单的解决方案：削减功能。正所谓：“如果你的指甲会导致你绊倒，那就切断它…”
基于我上面的发现，这意味着要禁用mediaText设置。但首先让我们看看mediaText是什么。根据W3C，它负责获取和设置媒体查询的集合。通过使用媒体查询， 可以针对特定范围的输出设备定制化呈现，而并不改变内容本身。所以基本上我们可以干扰网页布局。如果你看一下W3C给出的例子，会发现这些例子都使用静态媒体定义，而我将要做的补丁并不会对其产生影响，因为除非函数暴露在PoC依赖的JavaScript时才会产生影响。保护系统免受潜在的远程代码执行威胁，但可能换来某些页面样式的错误，这样是否值得你会有自己的选择。（0patch代理允许禁用补丁，如果你不能忍受它）。现在让我们看看补丁是如何工作的。
下面是我的0patch源文件内容。它为模块mshtml.dll定义了两个patchlet，位于patchlet_start 和patchlet_end之间。通过跟踪CSSMediaList对象上每个可能的setter（设置器）来获得Patchlet位置，CSSMediaList对象可以通过JavaScript访问到。我找到两个这样的位置：
media.mediaText设置器映射到CFastDOM :: CMediaList :: Trampoline_Set_mediaText
media.appendMedium方法映射到CFastDOM :: CMediaList :: Trampoline_appendMedium
我修补了这两个设置器，使它们的函数体被完全跳过（使用JUMPOVERBYTES指令），它们的结果通过xor rax，rax设置为SUCCESS。
;目标操作系统：Windows 7 64bit
;
RUN_CMD C： Program Files Internet Explorer iexplore.exe C： 0patch Patches CVE-2017-0037 poc.html
MODULE_PATH“C： Windows System32 mshtml.dll”
PATCH_ID 265
PATCH_FORMAT_VER 2
VULN_ID 2140
PLATFORM win64
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x00f79cc0
JUMPOVERBYTES 211;
code_start
xor rax，rax ; 返回SUCCESS
code_end
patchlet_end
patchlet_start
PATCHLET_ID 2
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x00fa3f80
JUMPOVERBYTES 197
code_start
xor rax，rax ; 返回SUCCESS
code_end
patchlet_end用0patch Builder 编译这个.0pp文件后，补丁将被应用，并且在IE11浏览器中运行PoC不会再崩溃。
如果您安装了0patch代理，补丁ZP-265到ZP-268应该已经存在于您的机器上。如果没有，您可以下载0patch代理的免费副本， 可以使自己在等待微软修复期间，避免遭受漏洞利用和现存问题之间的麻烦。注意，当微软的更新修复了这个问题，它会替换有漏洞的mshtml .dll ，我们的补丁将自动停止获得应用，因为它是严格绑定到DLL漏洞版本的。我们已经为以下平台部署了此补丁程序：Windows 10 64位，Windows 8.1 64位，Windows 7 64位和Windows 7 32位。
修补这个0day是一个展示我们0patch团队如何进行修补过程的好机会。我们很少发布取代官方供应商修复的补丁。一般来说，我们旨在弥补供应商更新版本与易受攻击电脑安装此更新版本的时间差。值得注意的是，在提供补丁的情况下，即直到下一个周二打补丁之前，我们谈论的不仅仅只是5天，因为对于很多公司来讲，从测试到正式更新批处理并可以应用到他们网络，这个时间差可以是几周也可以是几个月。
所以我们宁愿发布一个简单的临时补丁去阻止攻击者，而不是试图创建一个完美的补丁。对这个漏洞更彻底和更好的分析可以由微软完成。浏览器当然是最复杂的应用程序，所以使用我的黑盒分析工具及在有限的时间内，我也从不欺骗自己可以摸透所有关于HTML设备的细节。相比之下，微软开发者有源代码，正确的工具和知识可以完美地修复这个漏洞，并且可能还会在较短的时间内就完成。
总结
在微软提供正式修复之前（提供后我们绝对建议您应用），请随意使用0patch代理和该补丁，以保护自己免受CVE-2017-0037攻击。请记住，我们仍在测试中。
传送门
【技术分享】0patch一个0day漏洞：Windows gdi32.dll内存披露（CVE-2017-0038）