Chakra vulnerability debugging notes 1--ImplicitCall-vulnerability warning-the black bar safety net

Chakra is Microsoft’s next-generation browser, Microsoft Edge the Javascript parsing engine, 继承自IE浏览器的jscript9.dll and on GitHub open source for ChakraCore it. Chakra since open source has become a Windows platform vulnerability discovery one of the main goals, is also everyone to learn binary vulnerability mining very good practical projects.
The author in learning the Chakra vulnerability this months discover Chakra vulnerability study materials relative to the IE, Flash, etc. less, the disclosure of the exp number is also very limited. Fortunately Google Project Zero team disclosed that they have submitted the Chakra vulnerability case, which learn Chakra vulnerability very helpful:
! [](/Article/UploadPic/2019-6/201961917397315. png)
The author in the debug part of the case after the initiation of an idea: to turn these case according to from high to low, the ID number of the analysis process one by one record down and share with you, together to learn Chakra of vulnerability. Therefore with this series of the Chakra vulnerability debugging notes action. But the author level is limited, the vulnerability analysis is the use of spare time to complete, the text in the wrong place kindly treatise on.

0x1 ImplicitCall
Chakra the implementation process is divided into the interpreter execution（Interpreter and the JIT Just-in-time, the Interpreter executes the parse into byte code bytecode in the Javascript code, and explain the implementation process will be collected such as the type of a variable or function call number and other profile information. When a function or loop body is called multiple times, the Chakra will call the JIT compiler based on the previously collected profile information for the hot code is optimized and compiled into machine instructions JITed Code, and then generate the machine instructions replacement is to optimize a function or loop body entry point, such that after the hot spot function or a loop body invocation can be a direct implementation of the JIT compiler generates machine code, thereby improving JavaScript execution speed.
But Javascript is weakly typed, the variable type are generally can be modified dynamically, and the generated JIT code is strongly typed, the variable access of the Offset are fixed. In General, according to the profile information to generate the variable type is correct, but if the JIT code exists in the script callback, the situation will become more complicated.
To see an example:
! [](/Article/UploadPic/2019-6/201961917398649. png)
Assume that the Interpreter after executing Line 9 opt()after the Chakra will function opt() JIT, according to the profile information of the opt function inside o. a=0;generate the machine instruction like this: mov [o + 0x10], 0 where we assume that o. a in o offset 0x10 of
In the second implementation of the opt function before, since the Object prototypes bind the x property of the Get function, when the JIT is executed again to o. x it will trigger the__defineGetter__script callback, and in the__defineGetter__callback inside it is removed o the first property of a, and therefore the object o the layout has changed, 0x10 is not stored in a property.
__defineGetter__function returns once again back to the JIT if the JIT didn’t know the callback function__defineGetter__modify the object o to the layout, and still follow before the offset of the stored data: mov [o + 0x10], 0 will error.
Therefore a mechanism is needed to synchronize the Interpreter and JIT for the same variables changes, which is ImplicitCall it.
继续观察Demo1.js GlobOpt stage of Dump:
! [](/Article/UploadPic/2019-6/201961917398283. png)
Main concern here the first 5 rows can produce a script callback statement o. x-generated IR, you can see LdRootFld corresponding to the Bailout type is BailOutOnImplicitCallsPreOp, the LdFld corresponding to the Bailout type is BailOutOnImplicitCalls it.
继续观察Demo1.js Lowerer phase of the Dump, LdRootFld corresponding dump as follows:
! [](/Article/UploadPic/2019-6/201961917398190. png)
This code is mainly to do three things:
1: comparison of the GlobalObject of the Object Type is changed, there is no direct access to object o;
2: if the GlobalObject of the Type changes then compare the GlobalObject of the InlineCahe is changed, not in accordance with the InlineCahe to take the object o;
3: if if the GlobalObject of the InlineCahe also changed the call Op_PatchGetRootValue to get the object o.
And LdRootFld corresponding to the Bailout type is BailOutOnImplicitCallsPreOp, and therefore in the call Op_PatchGetRootValue before setting the ImplicitCallFlags=1, the DisableImplicitCallFlags=1, and in Op_PatchGetRootValue return after recovery DisableImplicitCallFlags=0 and compare ImplicitCallFlags ?= To 1. If ImplicitCallFlags != 1, the description of the Op_PatchGetRootValue call occurred during script callback, then trigger the Bailout: the SaveAllRegistersAndBailOut back to The Interpreter is.
Similarly LdFld corresponding Lowerer stage of the dump as follows:
! [](/Article/UploadPic/2019-6/201961917398915. png)
For BailOutOnImplicitCalls of the Bailout, the Lowerer of the post-phase will be in the May trigger the callback function before the set ImplicitCallFlags=1 and the function returns after relatively ImplicitCallFlags ?= 1, with the BailOutOnImplicitCallsPreOp logic is similar, not described in detail.
Then DisableImplicitCallFlags and ImplicitCallFlags what is it, why by setting these two Flag you can achieve the Interpreter and the JIT information to synchronize it? Chakra is by ExecuteImplicitCall achieve:
! [](/Article/UploadPic/2019-6/201961917398250. png)
Simply put Chakra through ExecuteImplicitCall to invoke the might of the script callback function, ExecuteImplicitCall the Interior first determines whether the called function whether there is a SideEffect, if not directly perform the call to the function; if DisableImplicitCallFlags=1 then do not perform the call function, direct return Undefined; otherwise, call the function before setting ImplicitCallFlags, and then call the function.
So in back to the JIT after the code you can check the ImplicitCallFlags has been modified to determine whether the occurrence of the script callback, and DisableImplicitCallFlags role apparently is to disable the callback again.

0x2 Case Study: CVE-2019-0568
Understand ImplicitCall mechanism, will naturally think of the Chakra need in can trigger a script callback function before the display call ExecuteImplicitCall, the

[1] [2] next