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地址要求下一步攻击载荷 ，，，，，，，最终达到远程代码执行。。 。。。。。
8827太阳集团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号