虛擬機 (VM) 能否“破解”在同一台物理機上執行的另一台虛擬機？
問題：
- 如果 VM 損壞（被黑客入侵），我對在同一物理機上執行的其他 VM 有什麼風險？
- 在同一物理主機上執行的虛擬機之間存在哪些安全問題？
- 有（你能列出）那些（潛在的）弱點和/或問題的清單嗎？
警告：
我知道存在許多虛擬化類型/解決方案，並且可能有不同的弱點。但是，我主要是在尋找有關虛擬化技術的一般安全問題，而不是特定的供應商錯誤。
請提供真實的事實、（嚴肅的）研究、經歷過的問題或技術解釋。請明確點。不要（僅）發表您的意見。
- 例子：
兩年前，我聽說可能存在與MMU相關的安全問題（我認為訪問其他機器的主記憶體），但我不知道這是否是今天的實際威脅，還是只是理論研究學科。
***編輯：*我還發現這種“Flush+Reload”攻擊能夠通過利用 L3 CPU 記憶體在同一台物理機器上檢索 GnuPG 密鑰，即使 GnuPG 在另一個VM 上執行也是如此。GnuPG 已被修補。
當然，給定一個有效的漏洞利用，可以利用在同一硬體上執行的另一個虛擬機。此外，可以存在一個。你的問題引用了一些最近的工作來展示一個。我不會在這里分享任何具體的漏洞利用或 PoC，但我會很高興地說它們是如何製作的。
在這種情況下使用的漏洞利用與在您試圖利用服務的同一台機器上執行時執行的漏洞利用自然不同，並且由於隔離性增加，它們往往會變得相當困難。但是，可用於完成此類攻擊的一些通用方法包括：
- 攻擊管理程序。如果您可以在給定虛擬機的管理程序上獲得足夠特權的外殼，您就可以控制系統上的任何虛擬機。解決這個問題的方法是尋找從 VM 到 hypervisor 的數據流，並且高度依賴於 hypervisor；諸如半虛擬化驅動程序、剪貼板共享、顯示輸出和網路流量之類的東西往往會創建這種類型的通道。例如，對半虛擬化網路設備的惡意呼叫可能會導致在負責將該流量傳遞到物理 NIC 驅動程序的管理程序上下文中執行任意程式碼。
- 攻擊主機上的硬體。許多設備允許韌體更新，如果碰巧可以從 VM 訪問該機制，您可以上傳符合您意圖的新韌體。例如，如果您被允許更新 NIC 上的韌體，您可能會導致它複製綁定到一個 MAC 地址（受害者的）但與另一個目標 MAC 地址（您的）綁定的流量。出於這個原因，許多管理程序會盡可能過濾此類命令。當 CPU 微碼更新源自 VM 時，ESXi 會對其進行過濾。
- 攻擊宿主的架構. 您引用的攻擊，本質上是另一種基於時間的密鑰洩露攻擊，這樣做：它利用記憶體機制對操作時間的影響來辨識受害虛擬機在其操作中使用的數據。虛擬化的核心是組件的共享；在共享組件的情況下，存在側通道的可能性。如果同一主機上的另一個 VM 在受害 VM 的上下文中執行時能夠影響硬體的行為，則受害 VM 由攻擊者控制。引用的攻擊利用虛擬機控制 CPU 記憶體行為（本質上是共享的通用狀態）的能力，以便受害者的記憶體訪問時間更準確地揭示它正在訪問的數據；只要存在共享的全域狀態，也存在披露的可能性。舉個假設的例子，想像一下攻擊 ESXi 的 VMFS 並使部分虛擬卷引用相同的物理磁碟地址，或者使記憶體膨脹系統相信某些記憶體可以共享而實際上應該共享的攻擊私有（這與使用後釋放或雙重分配漏洞的工作方式非常相似）。考慮一個虛擬機管理程序忽略但允許訪問的假設 CPU MSR（特定於模型的寄存器）；這可以用來在虛擬機之間傳遞數據，打破虛擬機管理程序應該提供的隔離。還要考慮使用壓縮的可能性，以便虛擬磁碟的重複組件僅儲存一次 - 在某些配置中可能存在（非常困難的）側通道，攻擊者可以通過寫入自己的虛擬磁碟並觀察來辨別其他虛擬磁碟的內容管理程序做什麼。當然，虛擬機管理程序應該防止這種情況發生，假設的例子是嚴重的安全漏洞，但有時這些事情會漏掉。
- 直接攻擊其他虛擬機。如果您有一個與受害虛擬機最近的主機，您可能能夠利用寬鬆的訪問控製或有意的虛擬機間通信，具體取決於主機的配置方式以及部署訪問控制時所做的假設。這只是稍微相關，但確實值得一提。
隨著時間的推移，特定的攻擊會出現並被修補，因此將某些特定機制歸類為可利用、僅在實驗室條件下可利用或不可利用是無效的。如您所見，攻擊往往涉及且困難，但哪些攻擊在特定時間可行是快速變化的，您需要做好準備。
也就是說，我上面提到的向量（在某些情況下可能除了最後一個向量）在裸機環境中根本不存在。所以是的，考慮到安全性是為了防止你不知道的漏洞利用以及那些已經公開披露的漏洞，你可以通過在裸機中執行或在至少在虛擬機管理程序不為所有人和雜項託管 VM 的環境中。
一般而言，安全應用程序程式的有效策略是假設電腦上執行著其他程序，這些程序可能受攻擊者控製或惡意，並使用可感知漏洞的程式技術，即使您認為以其他方式確保沒有此類程序存在於您的虛擬機中。但是，尤其是前兩個類別，請記住，誰先接觸硬體，誰就贏了。