虚拟机 (VM) 能否“破解”在同一台物理机上运行的另一个 VM？

从理论上讲，没有。管理程序的全部意义在于将虚拟机彼此隔离。

实际上，各种管理程序中已经存在（并且将来可能存在）安全漏洞，这些漏洞可能允许一个虚拟机影响同一主机上的管理程序或其他虚拟机。sVirt （用于 KVM/QEMU）等安全措施旨在解决这个问题。

当然，可以利用在同一硬件上运行的另一个虚拟机，只要有有效的利用。此外，一个可以存在。你的问题引用了一些最近的作品展示了一个。我不打算在这里分享任何具体的漏洞利用或 PoC，但我会很高兴地说出它们是如何制作的。

在此上下文中使用的漏洞利用自然不同于在您尝试利用服务的同一台机器上运行时起作用的漏洞利用，并且由于隔离度的增加，它们往往会更加困难。但是，可用于完成此类攻击的一些通用方法包括：

• 攻击管理程序。如果您可以在给定 VM 的管理程序上获得足够特权的 shell，则可以控制系统上的任何 VM。解决这个问题的方法是寻找从虚拟机到管理程序的数据流，并且高度依赖于管理程序；诸如半虚拟化驱动程序、剪贴板共享、显示输出和网络流量之类的东西往往会创建这种类型的通道。例如，对半虚拟化网络设备的恶意调用可能会导致在负责将流量传递给物理 NIC 驱动程序的管理程序上下文中执行任意代码。
• 攻击主机上的硬件。许多设备允许固件更新，如果碰巧可以从 VM 访问该机制，您可以上传符合您意图的新固件。例如，如果您被允许更新 NIC 上的固件，您可能会导致它复制绑定到一个 MAC 地址（受害者的）但具有另一个目标 MAC 地址（您的）的流量。出于这个原因，许多管理程序会尽可能地过滤此类命令；ESXi 会过滤来自 VM 的 CPU 微码更新。
• 攻击主机架构. 您引用的攻击本质上是另一种基于时间的密钥泄露攻击，它是这样做的：它利用缓存机制对操作时间的影响来识别受害虚拟机在其操作中使用的数据。虚拟化的核心是组件的共享；在共享组件的地方，存在侧信道的可能性。如果同一主机上的另一个虚拟机在受害虚拟机的上下文中运行时能够影响硬件的行为，则受害虚拟机由攻击者控制。引用攻击利用 VM 控制 CPU 缓存行为的能力（本质上是共享通用状态），以便受害者的内存访问时间更准确地揭示其正在访问的数据；只要存在共享的全局状态，也存在披露的可能性。举个例子，假设一个攻击 ESXi 的 VMFS 并使部分虚拟卷引用相同的物理磁盘地址，或者一个攻击使内存膨胀系统相信一些内存可以共享，而实际上它应该是私有（这与释放后使用或双重分配漏洞利用的工作方式非常相似）。考虑一个假设的 CPU MSR（模型特定寄存器），管理程序忽略但允许访问；这可用于在 VM 之间传递数据，打破管理程序应该提供的隔离。还要考虑使用压缩的可能性，以便虚拟磁盘的重复组件仅存储一次 - 在某些配置中可能存在（非常困难的）侧通道，攻击者可以通过写入自己的磁盘并观察来辨别其他虚拟磁盘的内容管理程序做什么。当然，虚拟机管理程序应该防范这种情况，假设的例子将是严重的安全漏洞，但有时这些事情会被忽略。
• 直接攻击其他虚拟机。如果您有一个靠近受害虚拟机的主机，您可以利用宽松的访问控制或有意的虚拟机间通信，具体取决于主机的配置方式以及部署访问控制时所做的假设。这只是稍微相关，但确实值得一提。

随着时间的推移，特定的攻击会出现并得到修补，因此将某些特定机制归类为可利用、仅在实验室条件下可利用或不可利用是永远无效的。如您所见，攻击往往涉及面广、难度大，但在特定时间哪些攻击可行是瞬息万变的，您需要做好准备。

也就是说，我上面提到的向量（在某些情况下最后一个可能例外）在裸机环境中根本不存在。所以，是的，鉴于安全性是为了防止您不知道的、不在野外的漏洞利用以及已公开披露的漏洞利用，您可以通过在裸机或在至少在管理程序不为所有人托管虚拟机的环境中。

一般来说，安全应用程序编程的一个有效策略是假设计算机上运行着其他进程，这些进程可能是攻击者控制的或恶意的，并使用漏洞感知编程技术，即使您认为您以其他方式保证没有这样的进程存在于您的虚拟机中。但是，特别是对于前两个类别，请记住，谁先接触到硬件，谁就赢了。

编辑：我以为这个话题几个月前就结束了，但它刚刚复活，现在 OP 要求更多的“真实事实、引用的研究”等，所以我想通了。

这种性质的利用是：

1. 稀有的
2. 本质上是敏感的，因此不会公开共享，当它们公开时，供应商会在该站点上的任何人知道它们之前修补漏洞
3. 复杂且因供应商而异

我们不能说破解管理程序并获得对其他 VM 的访问权限是不可能的。我们也无法量化存在多少风险，除非经验告诉我们它非常低，考虑到您不会发现许多利用虚拟机监控程序进行攻击的故事。

这是一篇相反的有趣文章，它表明已经进行了不止一些基于虚拟机管理程序的攻击。

然而，由于现在的技术比以往任何时候都更加依赖管理程序，因此与几乎任何其他类型的漏洞利用相比，此类漏洞利用都将更加紧迫地得到修补和防范。

以下是 IBM X-Force 2010 年中趋势和风险报告的摘录：

（请在新标签页中打开此图片以查看全尺寸图片。）

请注意“逃逸到管理程序”漏洞的测量百分比，这对我来说听起来很可怕。您自然会想阅读报告的其余部分，因为其中有更多数据来支持这些说法。

这是一个关于在 Playstation 3 管理程序上执行的可能漏洞利用的故事，这很有趣。可能对您的业务影响不大，除非您的业务是索尼，在这种情况下，它的影响非常大。

这是 VMware 的埃里克·霍施曼 (Eric Horschman) 写的一篇精彩文章，在我看来，他在文中有点像一个全力反对微软的青少年，但它仍然是一篇好文章。在本文中，您会发现诸如此类的花絮：

微软玻璃屋的居民还有一些其他的石头要扔给我们。Microsoft 指出 CVE-2009-1244 是 ESX 和 ESXi 中的来宾突破漏洞的示例。来宾突破利用是一项严肃的工作，但是，Microsoft 再一次歪曲了事实。VMware 迅速响应以修补我们产品中的该漏洞，而 ESX 受到的影响远没有 Microsoft 让您相信的那样：

竞争者之间的狡辩。但他在整篇文章中说的最清楚的话可能是：

事实上，对于任何企业软件而言，漏洞和漏洞永远不会完全消失。

OpenBSD 项目中经常被引用的 Theo de Raddt：

如果您认为世界范围内的软件工程师无法编写没有安全漏洞的操作系统或应用程序，那么您绝对是被迷惑了，如果不是愚蠢的话，然后可以转身突然编写没有安全漏洞的虚拟化层。

有点煽动性，但他的观点得到了很好的采纳。从理论上讲，虚拟化应该在虚拟机和它们的主机之间提供完全隔离。在实践中，偶尔会出现安全漏洞，允许高级攻击者绕过这些保护并获得对其他虚拟机甚至更糟糕的主机的访问权限（请参阅对恶意虚拟化环境主机的安全暴露的实证研究）。正如 Ryan Ries 提到的那样，这类漏洞非常罕见（这并不意味着它们不存在）并且通常不会被供应商披露，但它们确实存在。

如果您担心此类攻击的可能性（我认为在某种程度上您应该担心），我建议您不要在单个虚拟主机或虚拟主机集群上混合使用安全区域。例如 - 您将拥有一个用于 DMZ 虚拟机的专用双主机虚拟主机集群、一个用于中间件的专用集群和一个用于受保护资产的专用集群。这样，如果以允许攻击者破坏其他虚拟机或更糟的管理程序本身的方式利用漏洞，您的安全模型仍然完好无损。