Meltdown 和 Spectre 揭示超高速計算機的陰暗面

隨著 CES 在拉斯維加斯全面展開,上週安全重磅炸彈的部分責任研究人員權衡了可能的後果

本週在拉斯維加斯舉行的年度消費電子展 (CES) 上,數百家小工具製造商和軟體公司將最新產品的成功押注於英特爾、AMD、ARM 和其他公司的最新最強大的處理器。但在上週的重磅炸彈之後,即使按照罪惡之城的標準來看,這些賭注也顯得搖搖欲墜,因為許多處理器都受到被稱為 Meltdown 和 Spectre 的嚴重安全漏洞的困擾。

處理器為幾乎所有電子裝置(包括展覽中展示的數千輛汽車、家用電器和遊戲系統)提供了一定程度的智慧。現在已經很清楚,對更快處理器的貪得無厭的需求已經產生了陰暗面,因為晶片製造商在安全性方面偷工減料,使 可能數十億 臺個人電腦、移動裝置和其他電子產品在未來幾年內面臨新一輪的數字攻擊。

每臺計算機都依賴於一種稱為核心的軟體,除其他事項外,該軟體管理終端使用者應用程式(電子表格、Web 瀏覽器等)與底層中央處理器和記憶體之間的互動。核心啟動和停止其他程式,強制執行安全設定,並限制對裝置記憶體和資料資源的訪問。毫不奇怪,核心的速度決定了計算機的整體效能速度。晶片製造商透過將核心與其他在計算機上執行的程式隔離來保護核心,除非這些程式被授予特定許可權(或“特權”)以訪問核心。


支援科學新聞報道

如果您喜歡這篇文章,請考慮透過以下方式支援我們屢獲殊榮的新聞報道 訂閱。透過購買訂閱,您正在幫助確保有關塑造我們今天世界的發現和想法的具有影響力的故事的未來。


Meltdown 瓦解了這種隔離,可能會讓攻擊者的惡意軟體突破核心並竊取在那裡找到的任何資訊,包括個人資料和密碼。Spectre 削弱了核心阻止惡意程式從使用處理器的其他軟體竊取資料的能力。在 Google Project Zero、安全供應商 Cyberus Technology 和奧地利 格拉茨科技大學 獨立工作的研究人員協調了上週對 Meltdown 的公告。Spectre 的存在在大約同一時間浮出水面,這歸功於多所教育機構、網路安全研究公司和著名密碼學家 保羅·科切爾 (pdf) 分別進行的調查。

科切爾最出名的是他幫助修訂了一套用於保護計算機網路的密碼協議,他與大眾科學談論瞭如何透過增加處理器速度的捷徑導致了這兩種漏洞,為什麼花了數十年才發現這些漏洞,以及如何保護計算機免受攻擊。

[以下是對話的編輯稿。]

晶片製造商是如何為了創造更快的處理器而損害計算機安全的?
根本問題是處理器時鐘速度已基本達到極限。如果您想使處理器更快,則必須在每個時鐘週期內完成更多工作。另一個變化不大的因素是記憶體速度。因此,最佳化成為設計計算機處理器時提高速度的關鍵。例如,如果您的處理器到達一個等待記憶體資訊的位置,您不希望處理器在資料從記憶體返回之前處於空閒狀態。相反,處理器可以推測它將接收到的資訊,並開始提前工作而不是等待。當處理器猜測正確時,它可以保留這項額外的工作;處理器的推測執行帶來了顯著的效能提升。在正常情況下,由於處理器做出錯誤猜測並且必須回溯而損失的工作百分比是個位數。這種最佳化多年來一直是製造快速處理器的標準策略的一部分。

推測執行會產生哪些漏洞?
Meltdown 和 Spectre 都涉及這種捷徑,但它們的工作方式不同,並且具有非常不同的含義。Meltdown 利用了一個問題,即普通的非特權程式碼可以讀取具有核心許可權的記憶體。這使得能夠在其計算機上執行軟體的攻擊者讀取物理記憶體的全部內容——例如,這在多個客戶端共享同一伺服器的雲伺服器中是一個大問題。

相比之下,Spectre 不涉及任何特權提升問題。相反,它利用了被攻擊程式碼已經擁有的許可權,但欺騙使用者的系統推測性地執行程式永遠不會合法執行的操作,並且這樣做會洩漏記憶體內容。

是什麼促使您最終發現 Spectre 的研究?
時間是這樣的,我賣掉了我的公司(Cryptography Research),有時間親自動手做研究。最初讓我開始研究這個問題的是:我們在效能和安全性之間做了哪些權衡,以及在安全性不是首要任務的情況下增加了複雜性?在我報告這個問題並在我的[研究]論文中完全實施漏洞利用之後,我才完全意識到 Google Project Zero 在這方面的工作。時間是一個巧合,儘管實際上更令人驚訝的是,這些漏洞沒有在很久以前就被發現。

Meltdown 由多個研究小組獨立發現這一事實更有意義——部分原因是[安全研究員] Anders Fogh 在網上釋出了一篇文章,他在文章中調查了這個問題,但沒有發現問題。然後他發表了他的工作描述,這讓其他人開始思考這個問題。還有一項名為 KAISERkernel address isolation to have side-channels efficiently removed 的縮寫,核心地址隔離以有效消除側通道)的補丁集的工作,旨在解決針對 KASLR (核心地址空間佈局隨機化—一種安全技術,透過將各種物件放置在隨機而非固定地址來使漏洞利用更難) 的攻擊。事實證明,這是 Meltdown 的修復程式,因此它也引起了人們對這個問題的關注。

為什麼英特爾或其他晶片製造商沒有首先發現這個問題?
這是一個合理的問題。他們現在正在處理的爛攤子比他們立即發現並修復問題所經歷的痛苦要大得多。他們比外部研究人員更有優勢找到這些漏洞,因為他們非常詳細地瞭解所有技術的運作方式——而我是在沒有任何內幕知識的情況下四處摸索。特別是對於 Spectre,還值得問一下,為什麼 ARM 或更普遍地教授微處理器學術課程的計算機科學家沒有發現它。一種可能的答案可能是,人們傾向於關注他們知道要關注的事情,而 Spectre 涉及一個跨越不同學科的問題,即從事技術某一方面工作的人對其他方面瞭解不多。

儘管如此,如果一些安全人員密切關注推測執行,並考慮它可能出錯的不同方式,我認為他們中的很多人會意識到這是一個危險的想法。我懷疑在表面之下潛伏著更多令人不快的事情,我們沒有看到,因為關於安全影響的問題沒有被提出。

這對晶片設計的未來意味著什麼?
我認為現在有點戰爭迷霧,很難提出明確的答案。晶片製造商可以做不同的、非常高階的事情。其中之一是將其留給軟體開發人員來處理複雜的對策,但我認為這將在很大程度上失敗,因為開發人員沒有能力做到這一點。另一種方法是構建將具有不同安全屬性的核心組合在一起的晶片,並在同一晶片上具有單獨的執行單元,這些執行單元是更快還是更安全的執行單元。如果您在移動裝置上玩遊戲,則正在執行的是大型處理器核心。如果您的手機在休眠時收到資料包,則較小的核心會處理該資料包。

大多數真正關鍵的安全應用程式不需要大量效能。例如,如果您要進行電匯,則不需要大量[計算]能力來獲得使用者的確認以進行密碼學並傳輸結果。如果您正在玩影片遊戲,您真的不需要那種安全性,但它確實需要最佳效能。儘管如此,現在說 10 年甚至 5 年後情況會如何還為時過早。

這些漏洞的補丁如何降低處理器的效能?
Meltdown 的修復程式改變了核心記憶體的對映方式。在以前的工作方式中,普通使用者程式碼和核心之間的切換是非常輕量級的轉換。使用補丁後,必須在這些轉換上完成更多工作。對效能的影響將取決於工作負載的型別。如果幾乎所有程式的[數字運算]都在使用者模式下完成,並且很少切換到核心模式,您將看不到任何顯著的影響。相反,如果您有一段程式碼花費大量時間在使用者模式和核心模式之間快速來回切換——例如從儲存在非常快的磁碟上的檔案中讀取非常小的資訊位——最終會增加大量開銷。

Spectre 修復程式是如何工作的?
Spectre 目前只能緩解,而不能修復,因為該缺陷影響了許多不同的軟體,包括作業系統、驅動程式、Web 伺服器和資料庫。其中一些軟體(例如驅動程式)很少更新。許多軟體也非常複雜,因此開發修復程式是一項艱鉅的任務。對於某些 CPU,還有一些微程式碼補丁可以幫助緩解 Spectre 的一個方面,但是要使所有這些都正確工作,需要大量的工作。更糟糕的是,Spectre 涉及處理器中非常難以檢測到的東西,這使得對策的測試非常非常困難。一些晶片將不得不更換,因為它們無法更新。因此,這是一個將長期存在的問題。

計算機使用者如何保護自己?
在 Meltdown 方面,可以在作業系統級別實施許多修復程式——例如在 MacOS、Windows、Linux 和 iOS 作業系統更新中。如果您檢視 Meltdown 的軌跡,肯定有攻擊者可以並且將會攻擊未打補丁的計算機,因此迫切需要應用該補丁。一旦安裝了補丁,據我們所知,Meltdown 就不再是安全威脅。

另一方面,對於 Spectre,存在部分緩解措施。一些晶片無法更新,其他晶片可以更新,但製造帶有晶片的產品的公司不會費心傳遞更新。通常,更新不會解決所有問題。儘管如此,重要的是要保持對風險的看法。我們每天都生活在許多其他安全威脅之中。Spectre 不一定比已經給安全專業人員帶來巨大麻煩的其他漏洞更危險。使用 Spectre,您是在欺騙處理器在受害者計算機上執行的軟體的特定位置做出錯誤的預測。攻擊者需要了解受害者正在使用的軟體程式碼,併為攻擊工作設定正確的條件。因此,沒有一個可以在許多計算機上執行的單一攻擊程式。

從 Meltdown 和 Spectre 的發現中,最重要的啟示是什麼?
更大的圖景與我們如何處理安全以及我們即使在最需要安全的地方也無法使系統安全有關。這些錯誤是該問題的一種症狀。當您為與安全衝突的目標(例如速度)進行最佳化時,您可以合理地預期最終會遇到問題。Spectre 是安全/效能權衡的一個非常清晰的例子,其中速度最佳化直接導致了安全問題。這些安全漏洞影響所有主要的微處理器製造商這一事實確實表明,存在思想和注意力的失敗,而不是個人甚至單個公司犯下的具體錯誤。

© .