IE漏洞分析:CVE-2020-1380

  • A+
所属分类:安全文章

更多全球网络安全资讯尽在邑安全

IE漏洞分析:CVE-2020-1380

简介

作为8月份补丁的一部分,Microsoft修复了一个针对Internet Explorer 11的漏洞,特别是CVE-2020-1380。这是Internet Explorer的JavaScript引擎jscript9.dll中的UAF漏洞,在过去的几年中,我们观察到针对Internet Explorer的0-day攻击通常利用vbscript.dll和jscript.dll来运行shellcode。这次,目标更改为jscript9.dll,并使用现代JavaScript引擎的JIT来触发该漏洞,因此我决定深入jscrtip9.dll JIT引擎,试图找出CVE-2020-1380的具体原因。

 

Jscirpt9.dll执行管道概述

Jscript9.dll是默认的JavaScript引擎,用于替换从IE9开始的jscript.dll,下图显示了jscript9.dll的执行管道。

IE漏洞分析:CVE-2020-1380

通常,执行jscript9.dll中的JavaScript源代码有五个主要步骤:

  • 1.解析器解析JavaScript源代码以获得抽象语法树(AST)。

  • 2.字节码生成器遍历AST并生成字节码。

  • 3.解释器是执行字节码的虚拟机,在执行字节码时收集配置文件数据,例如类型信息。

  • 4.当某些代码片段被多次调用时,比如在for循环中,解释器将字节码和配置文件数据发送到后端JIT引擎以生成机器码,然后用生成的机器码替换字节码的入口点。

  • 5.在执行机器码时,如果某些状态违反了配置文件设定,机器码就会释放到解释器,再次执行字节码,以避免任何安全问题。

 

查找机器代码

在介绍这个漏洞之前,我们首先需要定位到JIT引擎生成的机器码。for循环通常在解释器中调用JIT引擎。下图显示了一个可以触发JIT的JavaScript代码:

IE漏洞分析:CVE-2020-1380

当循环计数大于某个阈值时(下图中的代码片段为0x32),循环体和内部调用函数opt将被发送到后端JIT引擎作业队列以生成优化的机器码:

IE漏洞分析:CVE-2020-1380

后端JIT引擎线程从队列中获取作业,最后调用jscript9!Func::Codegen生成优化的机器码:

IE漏洞分析:CVE-2020-1380

后端JIT引擎通过几个步骤来生成优化的机器码,如:构建IR(intermediate representation)、内联(inlining)、构建控制流图(CFG)、数据流分析、优化、分配寄存器、布局(layout)、编码等:

IE漏洞分析:CVE-2020-1380

当生成优化的机器码时,它将用于替换字节码循环体。当接下来调用for循环时,将改为在函数Js::InterpreterStackFrame::CallLoopBody中调用机器代码:

IE漏洞分析:CVE-2020-1380

最后,循环体机器码将内部调用opt函数的机器码,如下所示:

IE漏洞分析:CVE-2020-1380

 

CVE-2020-1380的漏洞原因

CVE-2020-1380的PoC如下图所示:

IE漏洞分析:CVE-2020-1380

以下步骤可以触发该漏洞:

  • 1.for循环将opt函数发送到JIT引擎

  • 2.在opt函数中,参数操作的三行代码可以将value2设置为value1,然后将Float32Array的第一个元素arr[0]设置为value1。

  • 3.opt函数被发送到JIT引擎后,它将参数value2从整数0x1337更改为具有回调函数valueOf的对象。

  • 4.在opt函数的最后一次调用中,由于参数’flag’设置为0,所以“if (flag == 1)”没有执行,它将value2设置为arr[0]。因为一个对象替换了value2,所以会发生隐式类型转换,然后可能会在机器代码中调用回调函数valueOf。

JavaScript是一种动态语言,类型或属性可以隐式转换。生成的机器代码在没有任何检查的情况下直接进行JavaScript隐式调用是不可信的。Jscript9.dll使用函数ExecuteImplicitCall来使JavaScript隐式调用安全。

首先,我们将三行“参数操作”更改为“arguments[0] = value2”,其效果相同;下图显示了生成JIT代码片段。

IE漏洞分析:CVE-2020-1380

在调用类型转换函数jscript9!Js::JavascriptConversion::ToFloat_Helper 之前,将一些值分别设置为存储在地址0x140F3F68和0x140F3E86中的flag。存储在0x140F3F68中的flag是ImplicitCallFlags,存储在0x140F3E86中的另一个flag是DisableImplicitFlags。DisableImplicitFlags设置为3(DisableImplicitCallFlag | DisableImplicitExceptionFlag),这表示从要调用的JavaScript代码进行隐式调用时(例如valueOf),不允许将类型转换为float。

JavascriptConversion::ToFloat_Helper函数检查输入类型,决定选择哪种类型转换。因为value2是一个对象,所以将调用Js::DynamicObject::ToPrimitive,然后最终将调用ExecuteImplicitCall:

IE漏洞分析:CVE-2020-1380

ExecuteImplicitCall检查DisableImplicitFlags;如果该值不等于0,则不会调用JavaScript隐式调用,并直接返回undefined。最后,机器码将转交给解释器(Interpreter),并在解释器中安全地调用隐式调用:

IE漏洞分析:CVE-2020-1380

但是,当使用三行“参数操作”替换“arguments[0] = value2”时,我们可以看到生成的机器代码直接调用Js::JavascriptConversion::ToFloat_Helper,而没有设置DisableImplicitFlags:

IE漏洞分析:CVE-2020-1380

最后,将直接从机器代码中调用隐式调用valueOf。攻击者可以利用这个不检查回调的机会来触发UAF漏洞,例如通过Worker线程对TypedArray的ArrayBuffer内存进行过滤。

IE漏洞分析:CVE-2020-1380

为什么这三行“参数操作”可以消除DisableImplicitFlags设置机器码引起了我的注意,我认为后端JIT GlobOpt阶段的arguments[0]的类型判断错误是根本原因。JIT引擎不知道Array.prototype的副作用,可用于更改arguments[0]的类型。在执行Array.prototype.push操作后应终止arguments[0]的类型,以避免出现这种类型判断错误的问题。

其他方法也可以触发这个漏洞,例如使用Array.prototype.splice或者使用Float64Array调用Js::JavascriptConversion::ToNumber_Helper的转换路径。这个漏洞也已经在8月补丁中修复。

IE漏洞分析:CVE-2020-1380

 

总结

在过去的几年里,针对Internet Explorer的0-day攻击通常利用vbscrpt.dll和jscript.dll漏洞。CVE-2020-1380是特殊的,因为它针对jscript9.dll的JIT引擎。JIT漏洞是V8,JavascriptCore,Spidermonkey和Chakra等现代JavaScript引擎中的常见问题。也许攻击者现在正在选择针对Internet Explorer的JIT引擎。

转自安全客

欢迎收藏并分享朋友圈,让五邑人网络更安全

IE漏洞分析:CVE-2020-1380

欢迎扫描关注我们,及时了解最新安全动态、学习最潮流的安全姿势!


推荐文章

1

新永恒之蓝?微软SMBv3高危漏洞(CVE-2020-0796)分析复现

2

重大漏洞预警:ubuntu最新版本存在本地提权漏洞(已有EXP) 




发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: