[[180043]]

引言

在本文中，我們將向讀者介紹在攻擊Internet Explorer和Edge瀏覽器時(shí)可用于繞過(guò)Microsoft的控制流防護(hù)(CFG)的方法。我們以前的概念驗(yàn)證性質(zhì)的漏洞利用代碼是通過(guò)覆蓋對(duì)象的函數(shù)指針來(lái)實(shí)現(xiàn)的。但是，當(dāng)遇到CFG時(shí)，這種方法就不太好使了。我們假設(shè)攻擊者已經(jīng)獲得了讀寫(xiě)內(nèi)存權(quán)限。

背景知識(shí)

CFG是微軟近來(lái)為Windows系統(tǒng)添加一種安全防護(hù)機(jī)制。該機(jī)制通過(guò)間接調(diào)用/跳轉(zhuǎn)指令的目標(biāo)地址的高效檢查來(lái)提供保護(hù)。如果您希望進(jìn)一步了解CFG的更多詳情，可以參閱參考文獻(xiàn)[1][2][3]，所以我們不做深入細(xì)致的講解。

雖然該緩解機(jī)制增加了控制流劫持型攻擊的難度，但是CFG本身并不完美。該技術(shù)的設(shè)計(jì)目標(biāo)是保護(hù)間接調(diào)用和跳轉(zhuǎn)，所以，沒(méi)有為堆棧(即ROP仍是可能的)提供保護(hù)。此外，值得注意的是，這是一個(gè)編譯時(shí)插樁技術(shù)，需要重新編譯源代碼。盡管微軟現(xiàn)在的許多二進(jìn)制文件可以受益于CFG，但還有很多其他程序不是利用CFG保護(hù)機(jī)制編譯的。

Chakra JIT

Chakra JIT負(fù)責(zé)為多次調(diào)用的函數(shù)和循環(huán)生成優(yōu)化的JIT代碼。這個(gè)過(guò)程分為多個(gè)階段完成，其中Full JIT Compiler和Garbage Collection階段是在后臺(tái)線程中進(jìn)行的。如果您有興趣的話，可以從MSDN上找到相關(guān)的工作流程和各種圖釋。

JIT工作流程

我們關(guān)注的重點(diǎn)是Full JIT Compiler階段，它負(fù)責(zé)獲取字節(jié)碼和輸出本地代碼。針對(duì)單個(gè)函數(shù)或循環(huán)的高級(jí)處理是在Func::Codegen()中進(jìn)行的。首先，它會(huì)生成字節(jié)碼的中間表示(IR)。然后，這些IR將被轉(zhuǎn)換若干次：優(yōu)化、寄存器分配、prolog和epilog等。一旦IR準(zhǔn)備就緒，就會(huì)被Encoder::Encode()編碼為本地代碼。

// https://github.com/Microsoft/ChakraCore/blob/master/lib/Backend/Encoder.cpp#L15 
void 
Encoder::Encode() 
{ 
    NoRecoverMemoryArenaAllocator localAlloc(_u("BE-Encoder"), m_func->m_alloc->GetPageAllocator(), Js::Throw::OutOfMemory); 
    m_tempAlloc = &localAlloc; 
... 
    m_encodeBuffer = AnewArray(m_tempAlloc, BYTE, m_encodeBufferSize); 
... 
} 

實(shí)際上，真正生成實(shí)際本地代碼的任務(wù)是由Encoder完成的。首先，它會(huì)分配m_encodeBuffer來(lái)臨時(shí)存放本地代碼。當(dāng)所有本地指令被發(fā)送到m_encodeBuffer之后，Encoder將對(duì)該緩沖區(qū)進(jìn)行重新定位，將其復(fù)制到read-only-execute內(nèi)存，并按照CFG的要求處理調(diào)用目標(biāo)。此時(shí)，該臨時(shí)緩沖區(qū)就不再使用，所以可以釋放了。

// https://github.com/Microsoft/ChakraCore/blob/master/lib/Backend/Encoder.cpp#L294 
... 
    m_encoderMD.ApplyRelocs((size_t) workItem->GetCodeAddress()); 
    workItem->RecordNativeCode(m_func, m_encodeBuffer); 
    m_func->GetScriptContext()->GetThreadContext()->SetValidCallTargetForCFG((PVOID) workItem->GetCodeAddress()); 
... 

注意，一旦代碼被復(fù)制到可執(zhí)行內(nèi)存后，就很難修改了。但是，當(dāng)Encoder在這個(gè)臨時(shí)緩沖器中生成本地代碼時(shí)，是無(wú)法防止攻擊者利用寫(xiě)入內(nèi)存權(quán)限來(lái)更改臨時(shí)緩沖器中的代碼的。由于JIT進(jìn)程位于后臺(tái)線程中，所以JavaScript線程仍然可以正常運(yùn)行。攻擊者的難點(diǎn)是找到該臨時(shí)緩沖區(qū)，并在Encoder運(yùn)行的極短時(shí)間內(nèi)完成相應(yīng)的修改任務(wù)。

繞過(guò)CFG防護(hù)

既然已經(jīng)知道了修改JIT代碼的基本方法，下面就讓我們付諸行動(dòng)，以便設(shè)法繞過(guò)CFG。

我們的過(guò)程分為三步：

觸發(fā)JIT。

查找臨時(shí)的本地代碼緩沖區(qū)。

修改緩沖區(qū)的內(nèi)容。

當(dāng)然，這里隱含的最后一步是執(zhí)行JIT處理過(guò)的代碼。

觸發(fā)JIT

第一步，也是最簡(jiǎn)單的一步，就是觸發(fā)JIT，讓它開(kāi)始對(duì)一個(gè)函數(shù)進(jìn)行編碼。為了使第二步變得更容易一些，我們希望函數(shù)的代碼多一些，以便我們有足夠的時(shí)間在內(nèi)存中尋找該臨時(shí)緩沖區(qū)。當(dāng)然，函數(shù)中的具體指令是無(wú)關(guān)緊要的。

var code = "var i = 10; var j = 1; "; 
for (var i = 0; i < 6000; i++) 
{ 
    code += "i *= i + j.toString();"; 
} 
code += "return i.toString();" 
f = Function(code); 
for (var i = 0; i < 1000; i++) 
{ 
    // trigger jit 
    f.call(); 
} 

查找本機(jī)代碼緩沖區(qū)

一旦后臺(tái)線程進(jìn)入Encoder::Encode()，我們需要快速找到臨時(shí)本地代碼緩沖區(qū)。發(fā)現(xiàn)緩沖區(qū)的一種方法是，找到給該緩沖區(qū)分配內(nèi)存的頁(yè)分配器，然后逐個(gè)查看它分配的內(nèi)存段。我們注意到，可以先找到ThreadContext，然后找到該后臺(tái)線程的BackgroundJobProcessor，這樣就可以找到該頁(yè)面分配器的引用了。

// find the ThreadContext using ThreadContext::globalListLast 
var tctx = readN(jscript9Base + 0x00349034, 4); 
// BackgroundJobProcessor 
var bgjob = readN(tctx + 0x3b0, 4); 
// PageAllocator 
var pgalloc = bgjob + 0x1c; 

PageAllocator具有若干已分配段的列表。由于經(jīng)JIT處理過(guò)的函數(shù)會(huì)變大，所以該臨時(shí)本地代碼緩沖器也將很大。所以，通過(guò)檢查largeSegments列表，我們就可以輕松找到該內(nèi)存段了。我們可以使用一個(gè)while循環(huán)，這樣一直等到這個(gè)largeSegments列表變?yōu)榉强?，然后進(jìn)入最后一步。

while (true) { 
    // read largeSegments list 
    var largeseg = readN(pgalloc + 0x24, 4); 
    // check if the list was empty 
    if (largeseg == pgalloc + 0x24) continue; 
    // get the address of the actual data 
    var page = readN(largeseg + 8 + 8, 4); 
    if (page == 0) continue; 
    break; 
} 

修改并運(yùn)行

現(xiàn)在，既然已經(jīng)知道了臨時(shí)本地代碼緩沖區(qū)的位置，那么接下來(lái)就可以修改其內(nèi)容來(lái)注入shellcode了。當(dāng)然，按理說(shuō)只要使用我們的shellcode覆蓋緩沖區(qū)的內(nèi)容就行了，但是實(shí)際上要比這個(gè)過(guò)程要復(fù)雜的多，因?yàn)槲覀儽仨毐苊飧采w未來(lái)在重定位步驟中將要修改的任何內(nèi)容。因?yàn)橛糜谟|發(fā)JIT的函數(shù)需要多次調(diào)用toString()，同時(shí)還要避免重定位的影響，所以，實(shí)際上可用于shellcode的空間并不充裕。

雖然最佳之選是修改要進(jìn)行JIT處理的函數(shù)，但這里選擇使用first-stage shellcode，它只是簡(jiǎn)單調(diào)用VirtualProtect，然后跳轉(zhuǎn)到我們的second-stage shellcode。這個(gè)first-stage shellcode通常是非常小(只有20個(gè)字節(jié))的。所以 ，我們可以把first-stage shellcode放到距這個(gè)緩沖區(qū)比較近的地方，然后在這個(gè)緩沖區(qū)的起始位置放上一個(gè)近轉(zhuǎn)移指令，從而跳轉(zhuǎn)至該代碼。

這樣的話，我們的second-stage shellcode可以是任何長(zhǎng)度，所以在我們的漏洞利用代碼中，使用了一個(gè)metasploit生成shellcode來(lái)執(zhí)行notepad.exe。實(shí)際上，這個(gè)second-stage shellcode還可以繞過(guò)保護(hù)模式(沙箱)。

在修改好臨時(shí)緩沖區(qū)之后，我們將進(jìn)入最后一步，就是進(jìn)行等待，直到JIT處理完成并執(zhí)行修改后的JIT代碼。為此，你可以不斷調(diào)用目標(biāo)函數(shù)，直到你的shellcode得到執(zhí)行為止。

for (var i = 0; i < 1000; i++) 
{ 
    // call overwritten jit block 
    f.call(); 
} 

漏洞利用

為了演示這種繞過(guò)技術(shù)，我們借鑒了此前用于Windows 10上的Internet Explorer 11的利用代碼，并進(jìn)行了相應(yīng)的修改。其中，獲取讀寫(xiě)內(nèi)存權(quán)限的代碼沒(méi)有改變，但是在執(zhí)行我們的shellcode的時(shí)候，使用的是JIT代碼覆蓋技術(shù)，而不是去覆蓋觸發(fā)CFG的函數(shù)指針。

你可以在https://github.com/theori-io/jscript9-typedarray-cfg頁(yè)面中找到最終的概念驗(yàn)證漏洞利用代碼。

安全影響

由于該CFG繞過(guò)漏洞的影響僅限于攻擊者已經(jīng)獲得了讀寫(xiě)內(nèi)存權(quán)限的情況，因此其實(shí)用性在現(xiàn)實(shí)中可能會(huì)受到一些限制。需要引起警覺(jué)的是，這個(gè)繞過(guò)方法具有內(nèi)置到Chakra JIT架構(gòu)內(nèi)部的優(yōu)勢(shì)，這意味著它可能很難修補(bǔ)，并且不會(huì)受到像英特爾的CET這樣的未來(lái)緩解措施的影響。

補(bǔ)救措施

微軟已經(jīng)承諾對(duì)ChakraCore進(jìn)行相應(yīng)的修改，以緩解我們發(fā)現(xiàn)的CFG繞過(guò)(以及其他CVE補(bǔ)丁)漏洞所造成的威脅。他們的基本思想是，在編碼器編碼指令時(shí)計(jì)算校驗(yàn)和，然后在將整個(gè)緩沖區(qū)復(fù)制到最終的RX(read/execute-only)緩沖區(qū)之后對(duì)校驗(yàn)和進(jìn)行驗(yàn)證。并且，只有通過(guò)驗(yàn)證后，JIT處理后的代碼的入口點(diǎn)才能作為有效的CFG目標(biāo)。這里的選擇的校驗(yàn)和算法是CRC32。