IE远程代码执行漏洞（CVE-2020-0674）分析
宣布时间 2020-03-092020年1月17日，微软宣布了针对IE远程代码执行漏洞（CVE-2020-0674）的Security Advisory(ADV200001)，并指出该0day漏洞已经被运用于针对性攻击。目前，微软已经宣布相关补丁进行修复。
该漏洞影响组件为jscript.dll，该动态链接库是微软Internet Explorer浏览器的Javascript引擎之一，其中IE8及以下使用jscript.dll，IE9及以上默认使用jscript9.dll，但网页可以通过<script>标签指定在IE8兼容性模式下加载jscript.dll，因此IE9、IE10、IE11都受到此漏洞影响。从操作系统范围来看，本漏洞影响范围横跨Windows 7至Windows 10中所有的个人操作系统和服务器操作系统。
该漏洞是一个Use-After-Free漏洞，攻击样本使用UAF告竣类型混淆，进而获取全局内存读写能力并绕过ASLR等漏洞利用缓解技术，并从指定ip地址请求下一步攻击载荷，最终到达远程代码执行。
东森平台ADLab宁静研究员凭据反病毒厂商捕捉到的样本对此漏洞进行了分析，发现漏洞CVE-2020-0674其实与CVE-2019-1429从漏洞原理上是同一个漏洞，但触发漏洞的样本截然差异，两次推出的补丁也不完全相同。
应对措施
使用Windows更新和补丁修复此漏洞。
禁用jscript.dll，Security Advisory(ADV200001)中已经给出：
漏洞和补丁分析
PART1
在开启页堆的IE浏览器中调试，瓦解现场如下：
凭据栈回溯可以对应到html样本的typeof调用。在样本中，经过庞大的引用操作，在arr3中，前一部门元素应该为undefined，后一部门元素应为RegExp工具，但使用typeof访问某元素时报错为“已释放的页堆空间”，可以看出这是一个由垃圾回收机制引起的问题。在用户默认设置下，即未开启页堆时，arr3中的某一个元素i会导致arr3[i]) === "number"建立，此时即引发类型混淆。
IE jscript的垃圾回收(Garbage Collect, GC)基于Mark-Sweep算法，即从界说为“根”的数据结构开始，寻找其所有引用到的工具标志为正在使用，而没有在标志的工具被看成不再使用，其内存空间将在垃圾回收过程中被释放。因此从瓦解现场看，本漏洞的成因是Mark-Sweep的标志过程泛起了问题，也就是工具之间的引用泛起了问题。
补丁分析的结论支持了上述推测。安装补丁后，对新旧jscript.dll进行bin diff，可以看到垃圾回收算法在多个工具的标志过程(Scavenge)着重处置了一个值为0x400C的特殊情况，以NameList工具为例：
凭据逆向分析和文档，这个枚举类型的值是VARIANT->VarType域。其中，0x400C代表该工具是一个指针类型的工具，指向另一个VARIANT，其指针域位于offset 8的位置，也即*((_DOWORD *)i + 2)�？梢钥吹�，此处的修补是取出指针值，通报给VAR::Scavenge函数。而VAR::Scavenge再次对0x400C的枚举型变量添加了特殊处置：
VAR::Scavenge函数对传入工具迭代地解引用，直到获得非指针的工具，也即若干层指针的最终指向，将其传入GcContext::ScavengeVar。GcContext::ScavengeVar函数逻辑较为简单，该函数通过与0xF7FF的与操作对传入工具进行标志，该与操作是将第12位清零。
经过测试，CVE-2019-1429与CVE-2020-0674的样本在各个“未修复”和“已修复”版本中体现完全一致。其UAF的工具的标志过程确实经由NameList::ScavengeCore，在CVE-2019-1429中是Array索引的Object工具，在CVE-2020-0674中是Array索引的RegExp工具，NameList::ScavengeCore决定了其是否被标志。
因此对于本漏洞的成因得出结论：在Mark-Sweep标志算法中，遇到指针类型的工具时应该解引用并标志对应工具；本例中，缺乏解引用的过程导致了漏洞的发生。
PART2
进一步分析可以发现，针对CVE-2019-1429和CVE-2020-0674微软先后推出了两个patch，以Windows 10 Version 1903 for 32-bit Systems为例，分别是KB4524570和KB4532693，但最终都升级到后者：
KB4524570和KB4532693都包罗了对上述漏洞核心原理的修复，其中前者对jscript.dll有较大改动，尔后者改动则简洁很多。KB4532693还包罗另一个革新，使用“冗余容灾”的思路提供了另一处加强；此处加强位于Javascript引擎中call和dispatch的基础设施中，而不是对种种工具逐个调停。
KB4532693对jscript.dll中的ScrFncObj::Call函数进行了重新组织，对于CallWithFrameOnStack和CallWithFrameOnHeap(自界说名称)这两种情况，用ScrFncObj::PerformCall统一。在ScrFncObj::PerformCall中，把调用使用的函数参数加入垃圾回收的“根”中：
经过验证，在PerformCall的加固下，即使NameList等工具泛起问题，在函数调用中作为参数的工具仍然被正确标志，不会触发漏洞。因而虽然两个补丁都可以完全抵御两个CVE的exploit，仍可以认为KB4532693是比KB4524570稍微高明一点的修补。
PART3
除此之外，两个补丁虽然能够在默认配置下抵御上述漏洞，对应jscript.dll仍然有一个称为LegacyGC的兼容项，已修补代码中仍然凭据GcContext::IsLegacyGCEnabled()的函数查询结果来判断检查是否介入。凭据逆向分析可知，该函数查询一个注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\ee1ca8aa-4402-4da1-bbe2-69a09c483a56
在此项为1时意为“兼容使用老的GC机制”，将使KB4532693中的加强失效，对于KB4524570则会完全失效。因此该注册表项的内容也涉及IE浏览器的宁静性，需要予以注意。
参考链接：
1.https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200001
2.https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1429
3.https://www.virustotal.com
京公网安备11010802024551号