[翻譯] Intel 處理器設計缺陷導致嚴重安全漏洞

原文鏈接：https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

原文標題: "內核內存泄露「 Intel 處理器設計缺陷導致 Linux、Window 必須重新設計

@永恆住民 翻譯，發佈於 零度之地 知乎專欄，水平有限，僅供參考，對文中論點保留意見

Intel 處理器的一個基礎設計缺陷導致 Linux、Windows 內核需要重新設計才能規避由此帶來的晶元級安全漏洞。

工程師正在努力修補開源操作系統 Linux 內核的虛擬內存子系統。與此同時，Microsoft 將在下周 2 的補丁更新上引入 Windows 系統的修補措施。這些更新在去年 11 月、12 月已經通過 Windows Insider 版本發布給了 Beta 測試用戶。

至關重要的一點，這些修補措施會對 Linux 和 Windows 系統在 Intel 處理器上的運行性能造成影響。影響的程度仍然在進行評估，大致範圍在 5% 到 30% 之間，並且在不同任務和不同的處理器下的影響程度不同。較新的 Intel 處理器上具備的一些功能，比如 PCID[1]，可以減輕一部分性能影響。所以最終用戶得到的結果會很不一樣。

PostgreSQL SELECT 1 在 Linux KPTI 修復方案中的影響[2]

最好情況: 17% 性能損失，最差情況: 23% 性能損失

— The Register (@TheRegister) January 2, 2018

其他操作系統，比如 Apple macOS 也需要更新。缺陷發生在 Intel 處理器硬體上，並且處理器微代碼更新（microcode update）似乎並不能修復這一缺陷，所以只能在操作系統層面上做修復 —— 或者買一塊沒有設計缺陷的新處理器。

或許是因為 Microsoft 在下周 2 才能發布補丁的緣故，漏洞的細節被禁止公開。Linux 內核的補丁 [3] 是公開可見的，但是為了掩蓋細節，源代碼的注釋被縮減了。

但是，一些細節已經浮出水面，這是我們所知道的。

影響

漏洞存在於過去十幾年 Intel 生產的現代處理器中。它允許普通用戶程序，從資料庫到瀏覽器中的 JavaScript 程序，推測受保護的內核內存區域的布局，甚至內容。

目前的修復方案被叫做 內核頁表隔離 (Kernel Page Table Isolation / KPTI)，它將內核內存從用戶進程中完全隔離出去。有段時間，Linux 內核團隊考慮使用 Forcefully Unmap Complete Kernel With Interrupt Trampolines (FUCKWIT) 作為修復方案的名稱，由此可見開發人員的心情。

每當一個運行中的程序需要做一些實際工作的時候，比如寫入文件，或者建立網路連接，它必須臨時將處理器控制權交給內核去執行。為了高效地在用戶態和內核態之間切換，內核在用戶進程的地址空間內做了一份映射，對於用戶進程而言這些都是不可見的。在需要內核的時候，用戶程序發起系統調用，處理器切換到內核態並進入內核。當任務完成的時候，處理器切換回用戶態，並回到用戶進程。在用戶態，儘管內核代碼和數據不可見，但是的確存在於用戶進程的頁表上。

內核就好像坐在雲端上俯瞰大地的神一樣，儘管沒有人能看到他，但是他的確在那裡，接受著眾人祈禱。

上述 KPTI 補丁將內核隔離到了一個完全不同的地址空間，不止是對用戶進程不可見，而是完全不在用戶進程的地址空間內了。這些本不需要的額外操作表明，Intel 處理器的設計缺陷導致內核訪問保護可以通過某種方法繞過。

隔離的代價非常昂貴，每次系統調用和硬體中斷都要在兩個地址空間上做切換。這些切換非常耗時，需要處理器轉儲緩存數據，從內存重新讀取信息。這增加了內核的工作量，並拖慢電腦速度。

最終結果就是，你的 Intel Inside 的電腦會運轉得更慢。

此次漏洞會如何被利用

最好的情況，此漏洞會惡意軟體和黑客用來開發其他安全漏洞。

最差的情況，此漏洞會導致惡意程序和任何已經登錄的用戶讀取內核的內存區域。內核的內存區域包含各種密鑰，密碼，登錄憑證，文件緩存等等數據。想想一下，跑在瀏覽器中的 JavaScript 代碼，或者運行在共享雲主機上的惡意軟體都能窺探包含在內核內存區域中的敏感信息，會是多麼可怕的場景。

一個典型的例子，此漏洞可以用來攻破 內核地址空間布局隨機化 (Kernel Address Space Layout Randomization / KASLR) [4] 防禦機制。該防禦機制被各種操作系統採用，它將內核的各個組件隨機分布在內存中，可以抵禦一部分對內核漏洞的利用，尤其是 ROP [5] 漏洞利用，這些都依賴於調用一個地址已知的現有的指令。

如果將內核代碼隨機分布在內存上，漏洞利用無法找到攻破系統所需的指令的地址。此次處理器缺陷有可能被用來找出內核代碼和數據在內存上的分布，因此才通過軟體層面的補丁進行緊急修復。

但是，此次處理器缺陷造成的影響可能遠不止如此。聖誕節的時候，AMD 往 Linux 內核郵件列表發了一封郵件 [6]（譯者註：並提交了修改，不在 AMD 處理器上啟用 KPTI），表示 AMD 不受影響。郵件的內容揭示了一些細節:

AMD 處理器的內核頁表隔離功能不受此次攻擊的影響。AMD 微構架不允許內存引用（memory references），包括預測引用（speculative references），在低許可權模式下訪問高許可權數據會導致分頁錯誤。

AMD 提到了 預測 (speculative)，現代處理器，包括 Intel 處理器，會進行預測執行。為了保持內部管線處於準備好執行指令的狀態，處理器核心會盡最大能力預測下一步要執行的代碼，獲取，並執行。

AMD 軟體工程師 Tom Lendacky 的話表明，Intel 處理器有可能在沒有安全檢查的情況下就預測執行了代碼。進而有可能通過這種方式，構建出一個軟體，讓處理器開始執行一個本該被阻止的指令，比如在用戶態讀取內核內存，並且在許可權檢查生效之前就完成指令的執行。

這會允許處於 Ring-3 級別的用戶代碼，讀取處於 Ring-0 級別的內核數據，會導致很壞的後果。

漏洞的詳細細節還沒有被確認，關於其嚴重性的討論也只是猜測。但是 Linux 和 Windows 在短時間內為此做了巨大的修改。這表明此次漏洞要比 KASLR 繞過更加嚴重。

另外，此次隔離內核和用戶地址空間的 Linux 補丁基於之前提出的 KAISER [7] 方案。KAISER 由 奧地利 Graz University of Technology 的一些研究人員提出。他們發現通過旁路攻擊處理器的虛擬內存組件可以獲取到內核的內存布局信息 [8]，進而有可能攻破 KASLR。該團隊提議隔離地址空間來阻止類似的信息泄露，他們的研究為此輪補丁提供了思路。

評估過他們的工作的 Anders Fogh 曾經在7月寫過一篇很有意思的博客 [9]。他曾經嘗試，通過爆用預測執行的方法，在用戶態讀取內核內存。雖然 Fogh 沒能得出概念驗證（PoC），他仍這樣寫道

我的結果證明了，預測執行的確會在違反了用戶態和內核態隔離的情況下繼續進行

這表明 KAISER 項目與 Fogh 有關。而 KAISER 的研究人員提出的攻擊手段也證明了 Fogh 是正確的，Intel 的 x86 處理器的確可以被惡意利用，進而在用戶態訪問到內核內存。

共享系統

此次漏洞對一些大牌雲計算環境造成了影響，包括 Amazon EC2，Microsoft Azure，Google Compute Engine。一個昵稱叫 Python Sweetness 的軟體工程師周一在博客 [10] 上這樣寫道：

一個禁止公開發表的安全漏洞影響了所有帶虛擬內存的的當代 [Intel] CPU 構架，必須更換硬體才能完全解決問題。Linux 內核的應對方案正在公開地開發中，並將在最近完成。NT 內核的類似方案在 11 月已經開始了。最差的情況下，這些修復措施會在常見工作負載下帶來明顯的性能降低。

有跡象表明，攻擊會影響常見的虛擬化環境，包括 Amazon EC2 和 Google Compute Engine...

運行著同樣數量的 Linux 和 Windows 系統的 Microsoft Azure 雲將在 1 月 10 日進行維護和重啟 [11]，有可能是為了應用這些修復補丁。

Amazon Web Services 也通過郵件提醒了用戶本周五會有安全更新 [12]，並未披露細節。

2017 年末有過某種虛擬機監管程序有一個嚴重漏洞的傳言，據說是 Xen，有可能與此次硬體缺陷漏洞有關。此次漏洞可以用來攻擊虛擬機監管程序，因此需要打補丁，進而有可能導致大量的客戶虛擬機需要重啟。

PS: 似乎 64位 ARM Linux 內核也會打 KAISER 系列補丁 [13]，用以完全隔離內核和用戶地址空間，阻止攻破 KASLR 的企圖，我們會在本周跟進。

[1] Process-Context Identifiers (PCIDs)

[2] heads up: Fix for intel hardware bug will lead to performance regressions

[3] Kernel Page Table Isolation (was KAISER)

[4] Kernel address space layout randomization

[5] ropasaurusrex: a primer on return-oriented programming

[6] Do not enable PTI on AMD processors

[7] IAIK/KAISER

[8] https://gruss.cc/files/kaiser.pdf

[9] Negative Result: Reading Kernel Memory From User Mode

[10] http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

[11] https://twitter.com/never_released/status/947935213010718720

[12] https://twitter.com/jschauma/status/941447173245370368

[13] arm64: Unmap the kernel whilst running in userspace (KAISER)