這讓我想起《1999：重返未來》中的暴雨，讓時代回到過去的雨。
- 作者：審核中尚未公開（同儕審查時，該不該讓審閱人知道論文作者是誰？ - PanSci 泛科學）
- 論文連結：https://openreview.net/forum?id=4tDNvQe2G0
- 發布日期：Aug 11, 2025
簡介
2017 年瞬態執行攻擊（Transient Execution Attack）如 Spectre 與 Meltdown 的發現引起全世界資安界的關注，多年以來做了不少針對這些攻擊的軟硬體修補措施來緩解攻擊。然而在現有的雲端服務中，許多伺服器依舊使用存有硬體漏洞的 CPU，雖然雲端服務業者如 Google 與 Amazon 對這些 CPU 加上軟體修補，但是這些修正大多是「打地鼠」式的修補，不能從根本上解決問題。若雲端服務業者從根本上修復這些硬體漏洞，則可能需要捨棄如預測執行（Speculative Execution）、快取等現代 CPU 用來提升性能的關鍵機制，將會嚴重影響伺服器性能。
本篇論文展示如何結合 L1TF 與 half-Spectre gadget 來從一台 VM 攻擊同一台伺服器上的另一台 VM，並取得其機密資料如 Nginx 的 RSA 私鑰。令人驚艷的是此攻擊在 Google Cloud 上奏效，且平均花費時間只有 14 小時，進而警告打地鼠式的修補措施是不足的，因為攻擊者仍有可能結合不同漏洞形成新的攻擊手段。
部分攻擊原理
L1TF
L1TF 是最早被發現的瞬態執行攻擊的其中一個漏洞。這個漏洞要求目標資料已經在 L1 快取中，理論上要取得這個資料需要先透過分頁表檢查 VA（虛擬記憶體位址）是否有效，然後再用 VA 作為索引存取 L1 快取。但在預測執行的情況下，CPU 不會檢查 VA 是否有效，而是直接讀取 L1 快取來加速執行速度。
後果是，若 CPU 還沒來得及檢查 VA 並中斷預測執行，那麼目標資料很有可能從 L1 快取中被讀取並移動到其他地方，攻擊者可進一步透過旁通道攻擊推敲目標資料的內容。而在 VM 的情況中，VM 就可以用自己的 VA 作為主機 VA 取得 L1 快取資料。
Half-Spectre
// Spectre gadget
if (index < ARRAY_SIZE) {
x = A[index];
y = B[4096*x];
}
// Half-Spectre gadget
if (index < ARRAY_SIZE)
x = A[index];
參考以上程式碼，傳統上的 Spectre 在預測執行時，假設 x 是機密資料，B[4096*x] 就會被帶進快取，攻擊者就可以暴力嘗試存取 B 的不同位置並統計存取速度，如果存取速度快就代表那個地方和 B[4096*x] 位於相同分頁，從而推得 x。
Half-Spectre 則是僅將 x 帶入快取，本篇論文再接著搭配 L1TF 將 x 從快取中讀出。
反思
治本與性能
這篇論文點出漏洞修補應該治本，若只採用打地鼠式的修補方法則無法保證攻擊者沒有其他利用該漏洞的攻擊手段，但實務上治本的修補所付出的性能代價太大，所以一般而言都還是在打地鼠。
對雲端服務的信任
這篇論文提出了可以攻擊其他 VM 的攻擊手法，且能在 Google Cloud 上成功運作。我們是否還能夠信任雲端服務業者能保護我們的系統安全？就算我們相信雲端服務業者不會攻擊我們的系統，我們也不可能相信同一台伺服器上的其他使用者。
硬體虛擬化與安全性
對於任何硬體，是不是如果主機不提供硬體模擬給 VM，而是讓虛擬機直接使用硬體，是否就會存在虛擬機可利用的硬體漏洞？在這篇論文的攻擊中，關鍵就是 VM 和主機共用 CPU 與其中的快取，導致 VM 可以利用硬體漏洞。如果我們能夠把 VM 用到的所有硬體都虛擬化，雖然這不實際，是否就能夠完全防止 VM 利用硬體漏洞？或是若非得讓 VM 與主機共用硬體，能不能切分硬體資源分給 VM 與主機，而不是同時使用？
值得學習的地方
由於作者能夠說服讀者這個攻擊能夠用於所有情況，因此作者只選擇一個攻擊標的 Nginx 來深入說明攻擊原理，避免焦點模糊。