1 概述

CET（Control-flow Enforcement Technology）機(jī)制是 Intel提出基于硬件的?于緩解 ROP/JOP/COP的新技術(shù)。特別強(qiáng)調(diào)下，他是基于硬件?持的解決?案。從Intel的Tigerlake (11th gen)，Alderlake (12th gen)/Sapphire-Rapid起，粗顆粒度地旨在預(yù)防前向（ call/jmp ）和后向（ ret ）控制流指令劫持來御防ROP的攻擊。

因此針對防御對象不同，CET技術(shù)又分為CET-SS用于針對ROP的ret指令和CET-IBT用于針對JOP/COP的jmp/call指令，見圖1 功守道。

圖1 功守之道

2 CET為何而生

在安全世界里，總是希望魔高一尺道高一丈。說到防御者CET，就不得不提他的進(jìn)攻者ROP了。什么是ROP? 來看?個(gè)例?，假設(shè)程序中正常執(zhí)行如下代碼?段，注意此時(shí)其中不含ret或call指令。

圖2 正常執(zhí)行流

但是，如果稍加偏移?下解釋代碼的地址時(shí)，就會導(dǎo)致出現(xiàn)完全不?樣的指令，如下圖所示：

圖3 RET CALL的gadget

如果按照紅框中的順序解釋這些指令的時(shí)候，那么將會產(chǎn)??代碼預(yù)期的結(jié)果，會出現(xiàn)原代碼中未出現(xiàn)過的 ret 指令以及 call 指令，這些指令序列被稱為 gadget 。

通過仔細(xì)構(gòu)造這些由ret指令終?的指令集，攻擊者可以執(zhí)?原程序中?預(yù)期的任意惡意代碼，這種新產(chǎn)生ret攻擊被稱為 ROP 攻擊，同理還有COP/JOP（call/jmp）攻擊。

為了防御這種此類ROP攻擊，Intel工程師在2016年起在硬件機(jī)制上推出了CET緩解機(jī)制，針對不同的攻擊行為分為CET-SS(影子棧)和CET-IBT(間接跳轉(zhuǎn)跟蹤)，即圖1 功守道所示。

3 CET

CET-SS和CET-IBT 在實(shí)現(xiàn)機(jī)制上屬于CPU內(nèi)部異常，這里就涉及到中斷機(jī)制。當(dāng)執(zhí)行啟動(dòng)CET發(fā)現(xiàn)執(zhí)行執(zhí)行流中沒有endbr64或函數(shù)返回ret和影子棧中shandow stack保存的ret不一致時(shí)，CPU內(nèi)部出發(fā)異常，這里CET占用的中斷向量21號，觸發(fā)#CP并歸為陷阱執(zhí)行中斷處理程序exc_control_protection()，對CET-SS CET-IBT分情況進(jìn)行報(bào)錯(cuò)。CET-IBT -> "traps: Missing ENDBR: xxx"， CET-SS-> #CP(control protect)。

這里提一下CPU的異常，當(dāng)CPU執(zhí)行中發(fā)現(xiàn)ROP/JOP/COP后，CPU給自己發(fā)送中斷信號。注意異常不一定是錯(cuò)誤，只要是異于平常就都是異常。有些異常不但不是錯(cuò)誤，它還是實(shí)現(xiàn)內(nèi)核重要功能的方法。CPU異常分為3類：

1.陷阱(trap)，陷阱并不是錯(cuò)誤，而是想要陷入內(nèi)核來執(zhí)行一些操作，中斷處理完成后繼續(xù)執(zhí)行之前的下一條指令；

2.故障(fault)，故障是程序遇到了問題需要修復(fù)，問題不一定是錯(cuò)誤，如果問題能夠修復(fù)，那么中斷處理完成后會重新執(zhí)行之前的指令，如果問題無法修復(fù)那就是錯(cuò)誤，當(dāng)前進(jìn)程將會被殺死；

3.中止(abort)，系統(tǒng)遇到了很嚴(yán)重的錯(cuò)誤，無法修改，一般系統(tǒng)會崩潰。CET歸為陷阱。

圖4 CET中斷異常處理流程

3.1 CET-SS（Shadow Stack）

3.1.1 原理分析

Intel 提出了?種基于硬件的 CET 解決?案，其中之?的 shadow stack 機(jī)制?于緩解 ROP 攻擊。前?圖2可以得知 ROP 依賴于 ret 指令，其中要執(zhí)?的后續(xù)指令地址從堆棧中獲得。因此 ROP 攻擊的前提是攻擊者能夠在堆棧中構(gòu)造數(shù)據(jù)。那么再來看 shadow stack 機(jī)制是怎么?作的。

CET 使操作系統(tǒng)能夠創(chuàng)建?個(gè) shadow stack （影?棧）。正常情況下，當(dāng)執(zhí)? call 指令時(shí)，會將 call 指令后?條指令地址壓棧。當(dāng)啟?了 shadow stack 后，會同時(shí)在普通數(shù)據(jù)棧和 shadow stack 中壓?返回地址，隨后在執(zhí)? ret 返回時(shí)，會將 shadow stack 中的返回地址和普通數(shù)據(jù)棧中的返回地址做對?，如匹配，則正常執(zhí)?，如不匹配，則觸發(fā)#CP(Controlflow Protection) 異常。如下圖所示：

圖5 CET-SS針對ret指令觸發(fā)#cp異常

3.1.2 驗(yàn)證方法

圖6 CET-SS test

以上內(nèi)核代碼以ko的形式進(jìn)行加載，然后通過用戶空間的app觸發(fā)系統(tǒng)調(diào)用，這里的app被名字也命為shadow_test_fork（內(nèi)核函數(shù)和app名字一致了，容易產(chǎn)生混淆，請大家理解）。系統(tǒng)調(diào)用最終調(diào)到圖6中的shadow_test_fork()函數(shù)。發(fā)生如下異常報(bào)錯(cuò)，見圖7。

圖7 CET-SS test result #CP

3.2 CET-IBT(Indirect Branch Tracking)

JOP/COP 攻擊?法與 ROP 類似，只不過是把 ROP 中以 ret 指令做跳板的關(guān)鍵點(diǎn)替換成了 call/jmp 指令。還是拿講述 ROP章節(jié)的兩幅圖（圖2 圖3）舉例，圖3中偏移解釋字節(jié)碼后出現(xiàn)了不同的指令，包含了：

圖8 CET-IBT call指令攻擊

這?指令序列，這就是 COP 中的 gadget ，以 call 指令為跳板，也就不需要 ret 指令的輔助了。這種不需要 ret 指令的攻擊場景下，前?所說的 shadow stack 機(jī)制就失效了。這種情況下， CET 的第?種機(jī)制 IBT(Indirect Branch Tracking) 就應(yīng)運(yùn)??了。

3.2.1原理分析

IBT(Indirect Branch Tracking),間接跳轉(zhuǎn)跟蹤"希望能防止攻擊者讓間接跳轉(zhuǎn)（例如，通過指針變量進(jìn)行的函數(shù)調(diào)用）進(jìn)入一個(gè)不應(yīng)該走到的地方。功守道之中是為了應(yīng)對JOP/COP的。

IBT 是為了防御面向跳轉(zhuǎn)編程的（jump-oriented programming）；工作原理是試圖確保每個(gè) indirect branch 的目標(biāo)確實(shí)都是適合作為跳轉(zhuǎn)目標(biāo)的。IBT 的方法有很多，每一種都有自己的優(yōu)勢和劣勢。例如，內(nèi)核在 5.13 開發(fā)周期中支持了編譯器實(shí)現(xiàn)的 IBT 機(jī)制。

在這種模式下，編譯器通過一個(gè) "jump table, 跳轉(zhuǎn)表" 來完成每一個(gè)間接跳轉(zhuǎn)，不僅確保目標(biāo)是要供間接跳轉(zhuǎn)使用的，而且要確保被調(diào)用函數(shù)的原型與調(diào)用者所期望的一致。這種方法是很有效的，但要增加很多編譯、運(yùn)行時(shí)的開銷。

英特爾的 IBT 方法相當(dāng)簡單，但優(yōu)點(diǎn)是得到了硬件的支持，因此速度更快.如果 IBT 被啟用，那么 CPU 將確保每個(gè)間接跳轉(zhuǎn)都落在一條特殊指令（endbr32 或 endbr64）上（見圖9），該指令執(zhí)行時(shí)跟 no-op 效果一致。如果發(fā)現(xiàn)意外，那么處理器將引發(fā)一次 control-protection（#CP）exception。

圖9 CET-IBT ENDBR標(biāo)志嵌入輔助檢測

3.3.2測試方法

圖10 內(nèi)核測試函數(shù)

圖11 CET-IBT 運(yùn)行測試結(jié)果

3.3 硬件機(jī)制.

CPU 是如何實(shí)現(xiàn)這種校驗(yàn)機(jī)制的呢？答案是?了 ENDBRANCH 狀態(tài)機(jī)。

CPU 在?戶態(tài)和內(nèi)核態(tài)分別設(shè)有?個(gè) ENDBRANCH 狀態(tài)機(jī)，狀態(tài)機(jī)共有兩個(gè)狀態(tài)，為 IDLE 和WAIT_FOR_ENDBRANCH 。初始狀態(tài)都為 IDLE ，當(dāng)執(zhí)?間接跳轉(zhuǎn) call 的時(shí)候，狀態(tài)機(jī)會從 IDLE變?yōu)閃AIT_FOR_ENDBRANCH ，這時(shí)候就意味著下?條指令就必須為 endbr32/64 ，如果是 endbr32/64 ，狀態(tài)機(jī)就會從 WAIT_FOR_ENDBRANCH 變回 IDLE ，如果不是則會觸發(fā) #CP 異常。

圖12 狀態(tài)機(jī)

3.4 其他objtool

需要在所有的間接跳轉(zhuǎn)目標(biāo)地址都添加 endbr 指令，這就為今后造成了一個(gè)潛在的陷阱：開發(fā)者可能會添加匯編函數(shù)但是忘記了這個(gè)指令。如果他們在沒有啟用 IBT 的情況下進(jìn)行測試，那么這個(gè)問題就不會被注意到，可能直到有問題的代碼被合并后的某個(gè)讓人非常不爽的時(shí)間點(diǎn)才突然暴露出來。為了防止這種情況的發(fā)生，開發(fā)者加強(qiáng)了內(nèi)核的 objtool 工具來檢查所有的間接跳轉(zhuǎn)，并確保所有的目標(biāo)都恰當(dāng)?shù)貥?biāo)注（annotated）好了。

不過，有了這種檢查之后，還可以采取另一個(gè)步驟：objtool 還可以列出所有包含 endbr 指令但是永遠(yuǎn)不會通過間接跳轉(zhuǎn)到達(dá)的函數(shù)。這些函數(shù)不需要進(jìn)行標(biāo)注，沒有它們的話，內(nèi)核會更安全一些。因此，內(nèi)核 build 的過程會從 objtool 中獲取該列表，并通過用 nop4 指令覆蓋 endbr 來 "封印" 這些函數(shù)。這就減少了攻擊者在啟用 IBT 時(shí)仍然可以選擇的攻擊目標(biāo)。

正如 Peter Zijlstra 所指出的，刪除不需要的 endbr 指令還有一個(gè)也許是令人驚訝的好處。內(nèi)核限制了 loadable module 所能使用的函數(shù)，而那些專有的（proprietary）module 則受限更多。那些專有的 module 經(jīng)常使用一個(gè)技術(shù)就是在內(nèi)核的符號表中查找到它們需要的、未 export 的函數(shù)，然后通過間接跳轉(zhuǎn)來調(diào)用它們，從而繞過內(nèi)核的限制。但是，在啟用 IBT 后，任何缺乏 endbr 指令的函數(shù)都不再能以這種方式調(diào)用了。

4 性能分析

圖13 遞歸調(diào)用

圖14 CET性能分析

圖15 CET 性能分析

5 內(nèi)核開發(fā)進(jìn)度

內(nèi)核開發(fā)者已經(jīng)努力了一段時(shí)間，希望能讓英特爾 IBT 功能進(jìn)入 Linux 內(nèi)核。實(shí)現(xiàn)這個(gè)功能的第一個(gè) patch（針對用戶空間代碼而不是針對內(nèi)核）是由 Yu-cheng Yu 在 2018 年發(fā)布的。然后，這項(xiàng)工作似乎成了那些不斷穿越郵件列表的飛行荷蘭人（flying-Dutchman）patch 之一，從未能夠進(jìn)入 mainline；第 30 版是 2021 年 8 月發(fā)布的，也沒有達(dá)到能夠合并的程度。類似的情況也發(fā)生在了用戶空間的影子堆棧（user-space shadow-stack）patch set 上，在經(jīng)歷多次修訂后，這些 patch 最近被 Rick Edgecombe 接手了。

2021年年底，Peter Zijlstra 決定創(chuàng)建一個(gè)獨(dú)立的英特爾 IBT 實(shí)現(xiàn)來保護(hù)內(nèi)核本身；第一個(gè)版是在去年 11 月發(fā)布的，Zijlstra 顯然是 "在周五晚上/周六早上趕工出來的"。這項(xiàng)工作發(fā)展得很快，3月初發(fā)布的第四個(gè)修訂版就是為 5.18 合并的版本了（鏈接見參考文檔CET-IBT patches）

這就是目前為止的情況了。從 2020 年底上市的 Tiger Lake 一代開始，英特爾處理器就支持 IBT 了，只支持了內(nèi)核代碼。這并不是一個(gè)完美的工具，但它將提高攻擊者攻擊這類系統(tǒng)的門檻。同時(shí)，目前還不清楚用戶空間的支持何時(shí)（或是否）會進(jìn)入 mainline 內(nèi)核；到目前為止發(fā)布的 30 個(gè)修訂版中，有許多根本沒有收到任何 review 意見。該部分已經(jīng)被Rick Edgecombe接手并發(fā)布了v1版本，后續(xù)我們拭目以待，希望能在6.2中會合入全部的CET代碼。

審核編輯：劉清