漏洞概述
该漏洞是由于 Chakra 引擎在优化过程中过于激进，删除了数组的边界检查而导致的数组越界漏洞
漏洞样本
漏洞样本从 yuange 那里的分析文档中获得
function write(begin,end,step,num)
{
for(var i=begin;i简要分析
在调试环境中打开样本，Edge 崩溃在如下位置，崩溃点及部分调用栈如下所示
0:018> r
rax=000100006e617579 rbx=000001c27ff90000 rcx=0000000000000005
rdx=000001ba16817fc0 rsi=000001ba057458a4 rdi=000000a3770fbe50
rip=000001ba058c013c rsp=000000a3770fbb40 rbp=000000a3770fbbe0
r8=0000000000010000 r9=000000003004000e r10=0000000040000010
r11=0000000000000001 r12=000000006e617579 r13=000100006e617579
r14=0001000040000010 r15=000100003000000e
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
000001ba`058c013c 4689248b mov dword ptr [rbx+r9*4],r12d ds:000001c3`40090038=????????
0:018> k
Child-SP RetAddr Call Site
000000a3`770fbb40 00007ff8`c9d1613a 0x000001ba`058c013c
000000a3`770fbbf0 00007ff8`c9d14d38 chakra!Js::InterpreterStackFrame::DoLoopBodyStart+0x30a
000000a3`770fbcb0 00007ff8`c9d1431e chakra!Js::InterpreterStackFrame::ProfiledLoopBodyStart<0,1>+0x48
000000a3`770fbd10 00007ff8`c9d1a6c8 chakra!Js::InterpreterStackFrame::OP_ProfiledLoopStart<0,1>+0xbe
000000a3`770fbd60 00007ff8`c9d16f23 chakra!Js::InterpreterStackFrame::ProcessProfiled+0x538
000000a3`770fbdc0 00007ff8`c9e1ec1d chakra!Js::InterpreterStackFrame::Process+0x143
000000a3`770fbe20 00007ff8`c9e1e71a chakra!Js::InterpreterStackFrame::InterpreterHelper+0x4bd
000000a3`770fc180 000001ba`159d0faa chakra!Js::InterpreterStackFrame::InterpreterThunk+0x5a
可以看出，程序崩溃在一段 JIT 代码中，根据调用栈可以看出程序是在调用 Loop 的过程中崩溃的，即发生在处理
for(var i=begin;i
// ......
000001ba`058c0120 453bca cmp r9d,r10d
000001ba`058c0123 7d42 jge 000001ba`058c0167
000001ba`058c0125 498bc5 mov rax,r13
000001ba`058c0128 4c8bd8 mov r11,rax
000001ba`058c012b 49c1eb30 shr r11,30h
000001ba`058c012f 4983fb01 cmp r11,1
000001ba`058c0133 0f85eb010000 jne 000001ba`058c0324
000001ba`058c0139 448be0 mov r12d,eax
000001ba`058c013c 4689248b mov dword ptr [rbx+r9*4],r12d ds:000001c3`40090038=????????
// ......
结合上面给出的崩溃时寄存器信息可以看出 ，r9 为 write(0x3000000e,0x40000010,0x10000,1851880825); 中第一个参数，这里 JIT 代码中并未进行任何边界判断，直接将 r9 当作数组下标进行访问，导致越界访问的发生。
一般情况下对于数组下标的访问均应先验证下标合法性，但是此处的 JIT 代码却没有这一部分。问题应该出在 JIT 代码产生的阶段
这里对说关于 JIT 代码的生成多说一些。
在 Chakra 引擎首先以解释器的形式执行 js 代码， 即将代码编译成为 byteCode，接着按字节顺序解析执行 byteCode 。 举例来说，如下所示一段 js 代码，Chakra 会首先将其变成 byteCode 的形式
for(var i=0;i<0x10000;i++)
{
view[index]=num;
}
生成的 byteCode 如下所示
// byte code
0x00000000000A8B70 a8 07 47 07 02 eb 00 ec 00 12 03 00 07 03 09 12 ?.G..?.?........
0x00000000000A8B80 00 6b 00 00 00 00 08 9b 06 08 05 00 00 28 07 07 .k.....?.....(..
0x00000000000A8B90 09 e4 ff ed 00 a8 00 24 00 00 00 00 00 00 00 00 .?.?.?.$........
0x00000000000A8BA0 c0 29 f7 01 00 00 00 00 80 bf ce 01 00 00 00 00 ?)?.....€??.....
0x00000000000A8BB0 50 fa cd 01 00 00 00 00 40 85 0a 00 00 00 00 00 P??.....@?......
0x00000000000A8BC0 10 e1 a5 d9 fe 07 00 00 00 00 00 00 00 00 00 00
eb 00 Js::InterpreterStackFrame::OP_ProfiledLoopBodyInit
ec 00 Js::InterpreterStackFrame::OP_ProfiledLoopBodyStart
12 03 00 07 03 Js::JavascriptOperators::Less
09 12 00 Js::InterpreterStackFrame::OP_Br
6b 00 00 00 00 08 Js::InterpreterStackFrame::OP_ProfiledGetRootProperty
9b 06 08 05 00 00 Js::InterpreterStackFrame::OP_ProfiledSetElementI
28 07 07 Js::JavascriptMath::Increment
09 e4 ff Js::InterpreterStackFrame::OP_Br
每个 byteCode 对应不同的处理函数，这个过程由函数 InterpreterStackFrame::ProcessProfiled 进行。对于循环体来说每次进入循环体都会先进入 OP_ProfiledLoopBodyStart 函数，用于记录循环的次数等信息。当一段 Loop 代码被执行了超过一定次数之后，便会进行 JIT 以优化程序的执行效率。
为了不影响 js 的正常执行 JIT 过程由一个独立的线程进行。JIT 线程首先以解释器的形式根据 byteCode 生成中间代码 IR，IR 是一系列指令的集合，构成一个双向链表。上文中的 byteCode 生成的 IR 如下所示
// OP_CODE
FunctionEntry(0x0155)
Label(0x0154)
Ld_I4(0x01bc)
ArgIn_A(0x01c1)
LdSlot(0x008c)
LdSlot(0x008c)
LdSlot(0x008c)
Ld_A(0x0047)
Ld_I4(0x01bc)
Ld_I4(0x01bc)
Ld_I4(0x01bc)
InitLoopBodyCount(0x01e1)
Br(0x0009)
Label(0x0154)
Ld_A(0x0047)
Ld_A(0x0047)
LdRootFld(0x006a)
Ld_A(0x0047)
BailOnNotEqual(0x0205)
FromVar(0x01b7)
FromVar(0x01b7)
BailOnNotArray(0x0210)
LdIndir(0x01c0)
BoundCheck(0x01dd)
BoundCheck(0x01dd)
LdIndir(0x01c0)
BailTarget(0x020a)
Label(0x0154)
StatementBoundary(0x0157)
IncrLoopBodyCount(0x01e2)
ByteCodeUses(0x0217)
BrGe_I4(0x0181)
Label(0x0154)
StatementBoundary(0x0157)
ByteCodeUses(0x0217)
Ld_A(0x0047)
NoImplicitCallUses(0x0219)
ByteCodeUses(0x0217)
StElemI_A(0x009a)
StatementBoundary(0x0157)
Incr_A(0x0028)
Br(0x0009)
Label(0x0154)
StatementBoundary(0x0157)
Ld_I4(0x01bc)
StSlot(0x01cf)
StLoopBodyCount(0x01e3)
Ret(0x0024)
Label(0x0154)
FunctionExit(0x0156)
接着 OP_Code (IR) 经一系列处理之后进入编译阶段生成最终的 JIT 代码。 JIT 代码生成之后 OP_ProfiledLoopBodyStart 函数便不会继续解释器模式而是直接跳转到 JIT 代码中执行。
查看 JIT 代码生成函数 Func::TryCodegen ，可以发现在函数实际生成 JIT 代码前会根据 函数流图 对程序进行优化
TryCodegen
{
// .....
IRBuilder irBuilder(this);
irBuilder.Build()
// ......
this->m_fg = FlowGraph::New(this, &fgAlloc);
this->m_fg->Build();
GlobOpt globOpt(this);
globOpt.Optimize();
// ......
Encoder encoder(this);
encoder.Encode();
}
其中OptArraySrc 用于对函数中用到的数组对象进行优化，注意到有如下代码，当 baseValueType （数组操作数的类型）是一个 VirtualTypedArray 时便可以通过优化检测，将 eliminatedLowerBoundCheck、eliminatedUpperBoundCheck、canBailOutOnArrayAccessHelperCall 优化标记设置。从而在其后产生代码时直接删除对与 Array 的下标检测。导致问题的发生。
// ......
if (baseValueType.IsLikelyOptimizedVirtualTypedArray() && !Js::IsSimd128LoadStore(instr->m_opcode) /*Always extract bounds for SIMD */)
{
if (isProfilableStElem ||
!instr->IsDstNotAlwaysConvertedToInt32() ||
((baseValueType.GetObjectType() == ObjectType::Float32VirtualArray ||
baseValueType.GetObjectType() == ObjectType::Float64VirtualArray) &&
!instr->IsDstNotAlwaysConvertedToNumber()
)
)
{
eliminatedLowerBoundCheck = true;
eliminatedUpperBoundCheck = true;
canBailOutOnArrayAccessHelperCall = false;
}
// ......
实际调试时可以发现程序在解析 StElemI_A 函数时会进入到此处优化判断， StElemI_A 相关 bytecode 如下
9b 06 08 05 00 00 Js::InterpreterStackFrame::OP_ProfiledSetElementI srcSlot(byte) baseSlot(byte) indexSlot(byte) profileId(word)
而参与优化检测的值 baseValueType 来源为 baseSlot(byte)，
Value *const baseValue = FindValue(baseOpnd->m_sym);
if(!baseValue)
{
return;
}
ValueInfo *baseValueInfo = baseValue->GetValueInfo();
ValueType baseValueType(baseValueInfo->Type());
Reference
[1] http://slab.qq.com/news/tech/1572.html