Spectre攻擊變種：Spectre 1.1和Spectre 1.2

與之前的Meltdown和Spectre CPU漏洞變種類似，Spectre 1.1和Spectre 1.2也利用了推測執行過程。

Spectre 1.1和Spectre 1.2簡介

Spectre 1.1

Spectre 1.1攻擊使用了推測執行來傳播能造成CPU緩衝區溢出的代碼，緩衝區溢出會導致能從之前安全的CPU存儲區域內提取數據的惡意代碼執行。

Spectre 1.1與之前的Spectre變種1和4非常相似，但研究人員稱截止目前，沒有有效的靜態分析或編譯工具能夠檢測或者緩解Spectre 1.1。

Spectre 1.2

Spectre3.0（Meltdown）是依賴頁表記錄（page-table entries，PTE）的User/Supervisor protection標記的lazy enforcement（延遲執行）。同樣的機制也可以用來繞過Read/Write PTE標記。Spectre 1.2就是依賴Lazy PTE強制執行的Spectrev1變種。在Spectre 1.2攻擊中，推測存儲可以用來覆寫只讀數據、代碼指針、代碼元數據等。即攻擊者利用Spectre 1.2漏洞可以向CPU內存區中只讀標記的區域寫操作。也就是說，Spectre 1.2漏洞使基於硬體的沙箱技術失效了。

與之前發現的Meltdown和Spectre漏洞類似，這兩個漏洞都需要用戶設備上存在運行攻擊所需的惡意代碼。但這一定程度上限制了bug的嚴重性。

影響

漏洞主要影響Intel和ARM晶元，AMD晶元好像也受影響。Intel和ARM已經公開承認部分CPU存在Spectre 1.1漏洞，但AMD並未發布相關聲明，不過AMD在安全問題上反應一直比較慢。因為所有的Spectre攻擊都影響AMD CPU，所以可以推測新的Spectre漏洞也影響AMD晶元。

研究人員沒有透露關於Spectre 1.2影響到CPU的信息。而且目前對這兩個漏洞，還都沒有發布補丁。

緩解措施

Microsoft、Oracle、Red Hat說他們也在分析Spectre 1.1漏洞是否影響各自廠家產品所處理的數據，也在研究軟體級緩解問題的方法。

文章中一共提出三種應對Spectre 1.1攻擊的硬體級的緩解措施。具體如下

Store-to-Load Blocking

這種攔截方法希望通過對當前晶元的微代碼的更新來預防store-to-load forwarding到推測的存儲或載入。這種微代碼上實施的可能性是未知的，如果這樣方法在很小複雜性的情況下是可行的，就可以在最小可信計算基（minimum trusted computing base，TCB）上提供最大的安全性。

這種方法可以對未打補丁的軟體做出最快的響應，可以教軟體開發者如何尋找有漏洞的代碼。總的來說，這種方法在性能可接受的情況下是非常安全的。

Lazy Store-to-Load Forwarding

這種方法使用的低複雜性和小TCB是非常有吸引力的。而且就算軟體不做改變的話，性能也是可以接受的。通過對編譯器的再次設計，可以獲取最優的性能。

Frozen Store-to-Load Forwarding

如果易出錯的軟體解決方案是推測執行攻擊的唯一可選方案，那麼需要做的就是設計更高性能的硬體。Arctic Sloth方法使用了動態檢測要轉發的store and load對的方法。一個更簡單的變種可以記錄之前在正確路徑上需要的store-to-load forwarding的load指令，並且接受來自任意存儲的數據。

這就需要一種更強的硬體地址推測機制，與高性能的Alpha處理器類似，這可能會對增加當前處理器的複雜度、功耗等。

附Spectre攻擊變種情況：

論文地址: https://people.csail.mit.edu/vlk/spectre11.pdf

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！