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地点请求下一步攻击载荷，，，，，，最终抵达远程代码执行。 。。。。。。
凯发k8ADLab清静研究员凭证反病毒厂商捕获到的样本对此误差举行了剖析，，，，，，发明误差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号