虚拟机 (VM) 能否“破解”在同一台物理机上运行的另一个 VM？
Tot*_*tor 12 security virtualization hacking virtual-machines hypervisor
问题：
- 如果 VM 损坏（被黑客入侵），我对运行在同一物理机上的其他 VM 有何风险？
- 运行在同一物理主机上的虚拟机之间存在什么样的安全问题？
- 是否有（你能列出）那些（潜在的）弱点和/或问题的清单？
警告：
我知道存在许多虚拟化类型/解决方案，并且可能有不同的弱点。但是，我主要是在寻找有关虚拟化技术的一般安全问题，而不是特定的供应商错误。
请提供真实的事实、（严肃的）研究、经历过的问题或技术解释。请明确点。不要（仅）发表您的意见。
- 例子：
两年前，我听说可能存在与MMU相关的安全问题（我认为访问其他机器的主内存），但我不知道这是否是今天的实际威胁，或者只是一项理论研究主题。
编辑：我还发现这种“刷新+重新加载”攻击能够通过利用 L3 CPU 缓存在同一台物理机器上检索 GnuPG 密钥，即使 GnuPG 运行在另一个VM 上。从那以后，GnuPG 就被打上了补丁。
当然，可以利用运行在同一硬件上的另一个虚拟机，前提是有一个有效的漏洞利用。此外，可以存在一个。你的问题引用了一些最近的工作来展示一个。我不会在这里分享任何具体的漏洞利用或 PoC，但我很乐意说明它们是如何制作的。
在这种情况下使用的漏洞利用自然不同于当您在尝试利用服务的同一台机器上运行时起作用的漏洞，并且由于增加了隔离，它们往往会变得相当困难。但是，可用于完成此类漏洞利用的一些通用方法包括：
- 攻击管理程序。如果您可以在给定 VM 的虚拟机管理程序上获得足够特权的 shell，您就可以控制系统上的任何 VM。解决这个问题的方法是寻找存在于从 VM 到管理程序的数据流，并且高度依赖管理程序；诸如半虚拟化驱动程序、剪贴板共享、显示输出和网络流量之类的东西往往会创建这种类型的通道。例如，对半虚拟化网络设备的恶意调用可能会导致在负责将流量传递给物理 NIC 驱动程序的管理程序上下文中执行任意代码。
- 攻击主机上的硬件。许多设备允许固件更新，如果碰巧可以从 VM 访问该机制，您可以上传符合您意图的新固件。例如，如果您被允许更新 NIC 上的固件，您可能会导致它复制绑定到一个 MAC 地址（受害者的）但具有另一个目标 MAC 地址（您的）的流量。出于这个原因，许多管理程序会在可能的情况下过滤此类命令；当 CPU 微码更新源自 VM 时，ESXi 会对其进行过滤。
- 攻击主机的架构. 您引用的攻击，本质上是另一种基于时间的密钥泄露攻击，这样做的目的是：它利用缓存机制对操作时间的影响来识别受害虚拟机在其操作中使用的数据。虚拟化的核心是组件的共享；在共享组件的情况下，存在侧信道的可能性。如果同一主机上的另一个 VM 在受害 VM 的上下文中运行时能够影响硬件的行为，则受害 VM 由攻击者控制。引用攻击利用虚拟机的能力来控制 CPU 缓存的行为（本质上是共享的通用状态），以便受害者的内存访问时间更准确地揭示其正在访问的数据；只要存在共享的全局状态，披露的可能性也存在。为了举个例子，想象一下攻击 ESXi 的 VMFS 并使部分虚拟卷引用相同的物理磁盘地址，或者攻击使内存膨胀系统相信某些内存可以共享，而实际上它应该共享私有（这与释放后使用或双重分配漏洞利用的工作方式非常相似）。考虑虚拟机管理程序忽略但允许访问的假设 CPU MSR（特定于模型的寄存器）；这可用于在 VM 之间传递数据，打破虚拟机管理程序应该提供的隔离。还要考虑使用压缩的可能性，以便虚拟磁盘的重复组件仅存储一次 - 在某些配置中可能存在（非常困难的）旁道，攻击者可以通过写入自己的内容并观察来辨别其他虚拟磁盘的内容管理程序做什么。当然，管理程序应该防止这种情况发生，假设的例子是严重的安全漏洞，但有时这些事情会漏掉。
- 直接攻击其他虚拟机。如果您有受害虚拟机的近端主机，您可以利用宽松的访问控制或有意的虚拟机间通信，具体取决于主机的配置方式以及在部署访问控制时所做的假设。这只是稍微相关，但确实值得一提。
随着时间的推移，特定的攻击会出现并被修补，因此将某些特定机制归类为可利用、仅在实验室条件下可利用或不可利用是永远无效的。如您所见，攻击往往涉及且困难，但在特定时间哪些可行是快速变化的，您需要做好准备。
也就是说，我上面提到的向量（在某些情况下可能会有最后一个例外）在裸机环境中根本不存在。所以是的，考虑到安全性是关于防止您不知道的漏洞利用以及那些不在野外以及已公开披露的漏洞利用，您可以通过在裸机或在至少在虚拟机管理程序不托管所有虚拟机的环境中。
通常，安全应用程序编程的有效策略是假设计算机上运行其他可能受攻击者控制或恶意的进程，并使用漏洞感知编程技术，即使您认为以其他方式确保没有此类进程存在于您的 VM 中。但是，尤其是前两个类别，请记住谁先接触硬件就会获胜。
编辑：我以为这个话题是在几个月前完成的，但它刚刚恢复，现在 OP 要求更多的“真实事实、引用的研究”等，所以我想出了什么。
这种性质的漏洞是：
- 稀有的
- 本质上是敏感的，因此不会公开共享，如果存在，供应商将在本网站上的任何人知道它们之前修补漏洞
- 复杂且因供应商而异
我们不能说破解管理程序并访问其他虚拟机是不可能的。我们也无法量化风险有多大，除非经验告诉我们风险非常低，因为您不会找到很多利用管理程序漏洞的攻击案例。
这是一篇相反的有趣的文章，它表明已经进行了不止一些基于管理程序的攻击。
然而，由于技术现在比以往任何时候都更加依赖虚拟机管理程序，与几乎任何其他类型的漏洞相比，此类漏洞的修补和防护都将更加紧迫。
以下是 IBM X-Force 2010 年中趋势和风险报告的摘录：
（请在新选项卡中打开此图片以查看全尺寸。）
请注意“Escape to hypervisor”漏洞的测量百分比，这对我来说听起来很可怕。很自然，您会想要阅读报告的其余部分，因为其中有更多数据来支持声明。
这是一个关于可能在 Playstation 3 管理程序上进行的漏洞利用的故事，很有趣。也许对您的业务没有那么大的影响，除非您的业务是索尼，在这种情况下，它的影响非常大。
这是来自 VMware 的 Eric Horschman 的一篇精彩文章，在我看来，他听起来像是一个完全反对 Micro$oft 的少年，但它仍然是一篇好文章。在本文中，您会发现诸如此类的花絮：
微软玻璃屋的居民还有其他一些石头可以扔给我们。微软指出 CVE-2009-1244 作为 ESX 和 ESXi 中来宾突破漏洞的一个例子。来宾突破漏洞利用是一件严肃的事情，但微软再一次歪曲了事实。VMware 迅速做出响应，修补了我们产品中的该漏洞，而 ESX 受到的影响比 Microsoft 会让您相信的要小得多：
竞争对手之间的争吵。但他在整篇文章中说的最清楚的可能是这样的：
事实是，任何企业软件的漏洞和漏洞利用永远不会完全消失。
小智 6
OpenBSD 项目中常被引用的 Theo de Raddt：
如果您认为全球范围内无法编写没有安全漏洞的操作系统或应用程序的软件工程师集合，那么您绝对是被迷惑了，如果您不是愚蠢的，那么可以转过身来突然编写没有安全漏洞的虚拟化层。
有点煽动性，但他的观点很好。理论上，虚拟化应该在虚拟机与其主机之间提供完全隔离。在实践中，偶尔会出现一些安全漏洞，允许高级攻击者绕过这些保护措施并访问其他虚拟机，甚至更糟的是他们的主机（参见对敌对虚拟化环境主机的安全暴露的实证研究）。正如 Ryan Ries 提到的，这些类型的漏洞非常罕见（这并不意味着它们不存在）并且供应商通常不会披露，但它们确实存在。
如果您担心此类攻击的可能性（我认为在某种程度上您应该如此），我建议您不要在单个虚拟主机或虚拟主机群集上混合安全区域。例如 - 您将拥有一个用于 DMZ 虚拟机的专用两台主机虚拟主机集群、一个用于中间件的专用集群和一个用于受保护资产的专用集群。这样，如果漏洞被以允许攻击者破坏其他虚拟机或更糟的管理程序本身的方式利用，您的安全模型仍然完好无损。