[[180043]]

引言

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

背景知識

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

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

Chakra JIT

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

JIT工作流程

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

實際上，真正生成實際本地代碼的任務(wù)是由Encoder完成的。首先，它會分配m_encodeBuffer來臨時存放本地代碼。當(dāng)所有本地指令被發(fā)送到m_encodeBuffer之后，Encoder將對該緩沖區(qū)進行重新定位，將其復(fù)制到read-only-execute內(nèi)存，并按照CFG的要求處理調(diào)用目標(biāo)。此時，該臨時緩沖區(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在這個臨時緩沖器中生成本地代碼時，是無法防止攻擊者利用寫入內(nèi)存權(quán)限來更改臨時緩沖器中的代碼的。由于JIT進程位于后臺線程中，所以JavaScript線程仍然可以正常運行。攻擊者的難點是找到該臨時緩沖區(qū)，并在Encoder運行的極短時間內(nèi)完成相應(yīng)的修改任務(wù)。

繞過CFG防護

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

我們的過程分為三步：

觸發(fā)JIT。

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

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

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

觸發(fā)JIT

第一步，也是最簡單的一步，就是觸發(fā)JIT，讓它開始對一個函數(shù)進行編碼。為了使第二步變得更容易一些，我們希望函數(shù)的代碼多一些，以便我們有足夠的時間在內(nèi)存中尋找該臨時緩沖區(qū)。當(dāng)然，函數(shù)中的具體指令是無關(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(); 
} 

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

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

// 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處理過的函數(shù)會變大，所以該臨時本地代碼緩沖器也將很大。所以，通過檢查largeSegments列表，我們就可以輕松找到該內(nèi)存段了。我們可以使用一個while循環(huán)，這樣一直等到這個largeSegments列表變?yōu)榉强眨缓筮M入最后一步。

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; 
} 

修改并運行

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

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

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

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

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

漏洞利用

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

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

安全影響

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

補救措施

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