各大操作系統誤讀英特爾文檔致內核可被劫持或崩潰
責編：gltian ｜2018-05-16 10:18:15Chipzilla手冊更新，請及時打上補丁。
Linux、Windows、macOS、FreeBSD和Xen的某些實現都存在設計缺陷，攻擊者可利用該缺陷導致英特爾和AMD計算機系統崩潰。
更糟的情況是，黑客還有可能獲取到敏感內存信息或控制底層操作系統功能，也就是能窺探內核內存或劫持機器運行的關鍵代碼。
惡意登錄用戶或計算機上運行的惡意軟件都可以利用該漏洞。不過，這一幾乎波及全行業范圍的編程缺陷目前已有可用補丁加以緩解。
5月8號CERT發布的公告稱，該編號為CVE-2018-8897的安全漏洞，是因為微軟、蘋果和其他公司錯誤理解了英特爾和AMD芯片處理某一特定異常的方式。
CERT寫道：“該錯誤似乎是因開發人員對現有文檔的解釋而產生的。”換句話說，程序員理解錯了英特爾和AMD的手冊，雖然這些手冊可能寫得不是特別清楚。
觸發中斷
問題的核心是 POP SS 指令。該指令從當前程序的堆棧取得用于堆段選擇的值，并將該值放入CPU的堆棧選擇寄存器。但現代操作系統大多忽略了內存分段問題。CPU會特別處理 POP SS 指令，以便執行中遇到中斷時堆棧能保持一致狀態。
應用程序可為堆棧選擇器即將被 POP SS 指令從堆棧中取出的內存位置設置調試斷點。設置了該調試斷點后，當應用程序調用 POP SS 指令時，只要處理器訪問RAM特定位置讀取該堆棧選擇器，就會拋出一個特殊異常。
問題就出在這兒。要利用這一情況，緊跟在 POP SS 指令后的那條指令必須是觸發中斷的INT指令。這些由軟件產生的中斷有時候是用戶程序用以激活內核，讓內核為當前進程干活的，比如打開個文件之類。
在英特爾和AMD機器上，緊跟在 POP SS 后面的軟中斷指令會讓處理器進入內核的中斷處理過程。然后調試異常就出現了，因為 POP SS 導致該異常被延遲。
操作系統設計者并沒有預期到這一點。他們閱讀英特爾的x86-64手冊，認為內核中斷處理過程是在不可中斷的狀態下開始的。但如今，中斷處理過程在初期就遭遇到了非預期的調試異常。
漏洞發現者的技術報告中解釋稱，這導致了內核的混亂，特定情況下，內核的動作完全依賴于非特權用戶所控制的數據。
如果 POP SS 指令執行時調試寄存器設置了堆棧位置訪問的斷點，且緊跟的指令就是 INT N，那么在進入中斷門之后，掛起的 #DB 就會被觸發，因為那是最有可能的分支指令。不是不可屏蔽的中斷，也不是機器檢查異常，操作系統開發人員直接為中斷門語義假定了一個不可中斷的狀態。這會導致操作系統監管軟件在設計時出現漏洞，使用中可能會錯誤地采用了非特權軟件選擇的狀態信息。
這是操作系統提供商因為 POP SS 指令及其與中斷門語義互動的文檔不清晰不完整而犯下的嚴重安全疏漏。
其結果就是，在英特爾主機上，用戶應用程序可使用 POP SS 和 INT 指令來利用上述的錯誤理解，控制中斷處理過程中的特殊指針GSBASE；而AMD主機上，應用程序可控制GSBASE和堆棧指針。黑客可利用該漏洞觸及未分配內存，抽取部分受保護內核內存，最終使內核崩潰；或者調整其內部結構，擾亂系統運行。
雖然任何漏洞利用嘗試都更容易搞崩內核而不是引起什么嚴重傷害，但是與熔斷之類的漏洞一樣，這是整個行業的恥辱，應該盡快被補上。
操縱
FreeBSD對該問題的解釋則更進一步：“在x86架構的系統上，堆棧是由堆棧段和堆棧指針共同表示的，其正常運行需要二者協調一致。操作堆棧段的指令有特殊的處理過程來保持與堆棧指針的改變相一致。”
MOV SS 和 POP SS 指令會抑制調試異常直到下一條指令的邊界。如果該指令是一條系統調用或者將控制傳遞到操作系統的類似指令，調試異常就會在內核環境中處理，而不是在用戶環境中處理。
其結果就是通過了身份驗證的本地攻擊者可以讀取到內核內存中的敏感數據，控制底層操作系統功能，或者直接搞崩系統。
微軟的內核建議表明，在Windows主機上利用該漏洞，需要攻擊者先登錄到系統，再運行精心制作的應用程序以奪取受影響系統的控制權。
這并非危言聳聽，除非你的主機上從來都不運行任何不可信的代碼。
Red Hat 已經準備好放出補丁，Ubuntu和macOS同樣做好了補丁準備。
Linux內核早在 2018年3月23號就打上了補丁，版本4.15.14、4.14.31、4.9.91、4.4.125以及更老的4.1、3.16和3.2都已修復。
微軟也解決了該問題，補丁覆蓋 Windows 7 到 Windows 10，Windows Server 2008 到 Windows Server 1803。Xen為版本4.6到4.10打了補丁。VMware的虛擬機管理程序沒有風險，但 vCenter Server 的一個工作區和vSphere集成的容器需要打補丁，但都只是“可能”受影響。
所有資料來源都痛苦地指出，雖然該問題源自x86-64指令集，但需承擔責任的卻是內核程序員而（不是Chipzilla）。似乎是很多程序員都理解錯了調試異常的處理方法，在很長一段時間里重復著相同的錯誤。
既然英特爾已經更新手冊澄清了堆棧選擇器指令的處理方式，或許大量操作系統開發人員都得去重新學習x86-64架構。用戶也得緊急修復自己的系統——這種事如今用戶應該已經非常習慣了。
英特爾發言人稱：
我們重視客戶和合作伙伴的安全。 為確保與開發者社區的明晰溝通，我們更新了《軟件開發者手冊》(SDM)，澄清了 POP/MOV-SS 指令的安全用法。我們建議系統軟件廠商評估其軟件以證實自身產品能處理上述問題。