Checkpoint提出Safe-Linking保護技術,讓漏洞變得更加困難

關卡公司 呈現 安全連結保護機制,這使得很難創建操縱執行 malloc 呼叫時分配的緩衝區指標的定義或修改的漏洞。安全連結並不能完全阻止利用漏洞的可能性,但它會以最小的開銷使某些類別的漏洞利用的創建變得非常複雜,因為除了可利用的緩衝區溢出之外,還需要找到另一個導致資訊外洩的漏洞堆在記憶體中的位置。

已為 Glibc (ptmalloc)、uClibc-NG (dlmalloc)、gperftools (tcmalloc) 和 Google TCMalloc 準備了實現安全連結的補丁,並且還建議升級 Chromium 中的保護(在
自2012年以來,Chromium已經內建了MaskPtr保護技術,旨在解決相同的問題,但Checkpoint的解決方案表現出了更高的效能)。
建議的補丁已被批准在 8 月版本中交付 Glibc 3.32 預設將啟用安全連結。 uClibc-NG 支援安全鏈接 進入 包含在版本 1.0.33 中並預設為啟用。 gperftools 的變化(舊的 tcmalloc) 公認,但將在未來版本中作為選項提供。

開發人員 TCMalloc (new tcmalloc) 拒絕接受 改變,理由是效能嚴重下降,並且需要添加大量測試來定期檢查一切是否按預期工作。 Checkpoint工程師測試表明,Safe-Linking方法不會導致額外的記憶體消耗,執行堆操作時的性能平均僅降低0.02%,最壞情況下降低1.5%(作為對比,開銷為Chromium 中使用的方法估計為“低於2%”)。包容性
安全連結會導致每次呼叫 free() 時執行 2-3 個額外的組譯指令,每次呼叫 malloc() 時執行 3-4 個指令。不需要運行初始化和隨機值產生階段。

Checkpoint提出Safe-Linking保護技術,讓漏洞變得更加困難

安全連結不僅可用於提高各種堆疊實現的安全性,還可用於在使用放置在緩衝區本身旁邊的指標單鍊錶的任何資料結構添加完整性控制。此方法實作起來非常簡單,只需要新增一個巨集並將其應用於指向程式碼中下一個區塊的指標(例如,對於 Glibc 變化 只需幾行程式碼)。此方法歸結為以下變化:

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- 下一個p = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

此方法的本質是利用ASLR位址隨機化機制(mmap_base)中的隨機資料來保護Fast-Bins和TCache等單鍊錶。在將該值套用於指向清單中下一個元素的指標之前,它會執行遮罩轉換並檢查頁面對齊情況。此指標被「(L >> PAGE_SHIFT) XOR (P)」運算的結果替換,其中 P 是指標的值,L 是儲存指標的記憶體位置。

Checkpoint提出Safe-Linking保護技術,讓漏洞變得更加困難

在系統中使用時 ASLR (位址空間佈局隨機化)帶有堆基位址的L位元的一部分包含隨機值,這些值用作編碼P的密鑰(透過12位元組頁面的4096位移位元操作提取)。這種操作降低了漏洞中指針劫持的風險,因為指針不是以其原始形式存儲的,並且替換它需要了解堆分配。此外,補丁代碼還包含對區塊對齊的額外檢查,這不允許攻擊者用未對齊的值替換指針,並且需要了解對齊的位數,這在 64 位元系統上還允許阻止15 次攻擊嘗試中有16次沒有考慮對齊情況。

此方法可有效防止使用部分指標重寫(更改低位元組)、完全指標重寫(重定向到攻擊者的程式碼)以及更改未對齊位址處的清單位置的攻擊。作為一個例子,它表明在 malloc 中使用安全連結將允許最近阻止利用 已確定 由同一漏洞研究者 CVE-2020,6007 在飛利浦 Hue Bridge 智慧燈中,由緩衝區溢位引起並讓您獲得對設備的控制。

來源: opennet.ru

添加評論