虚拟机（VM）可以“破解”运行在同一物理机器上的另一个虚拟机吗？

当然有可能利用在同一硬件上运行的另一个虚拟机，给出一个工作的利用。 另外，可以存在。 你的问题引用了一些最近的工作。 我不打算在这里分享任何具体的漏洞利用或PoC，但我会很乐意地说，他们是如何做到的。

在这个上下文中使用的漏洞与当你在同一台机器上运行，而你尝试利用服务的漏洞有着天然的区别，而且由于隔离度的增加，漏洞往往会变得更加困难。 但是，可以用来实现这种利用的一些一般方法包括：

• 攻击pipe理程序 。 如果您可以在给定虚拟机的虚拟机pipe理程序上获得足够特权的shell，则可以控制系统上的任何虚拟机。 解决这个问题的方法是查找从虚拟机到虚拟机pipe理程序的数据stream，并且依赖于pipe理程序。 像半虚拟化驱动程序，剪贴板共享，显示输出和networking通信等往往会创build这种types的通道。 例如，对半虚拟化networking设备的恶意调用可能导致在pipe理程序上下文中执行任意代码，负责将stream量传递给物理网卡驱动程序。
• 攻击主机上的硬件 。 许多设备允许固件更新，如果碰巧有可能从虚拟机访问该机制，则可以上传支持您的意图的新固件。 例如，如果允许更新NIC上的固件，可能会导致它复制一个MAC地址（受害者）的stream量，但另一个目标MAC地址（您的）。 为此，许多虚拟机pipe理程序尽可能地过滤这些命令; ESXi在从VM发起时过滤CPU微代码更新。
• 攻击主机的体系结构 。 你所引用的攻击，基本上是另一个基于定时的关键泄露攻击，它是这样做的：它利用caching机制对操作时间的影响来辨别受害VM在其操作中使用的数据。 虚拟化的核心是组件的共享; 在共享组件的情况下，存在侧通道的可能性。 如果同一主机上的另一个虚拟机能够在受害虚拟机的上下文中运行时影响硬件的行为，则受害虚拟机由攻击者控制。 被引用的攻击利用虚拟机控制CPUcaching行为（本质上是共享的通用状态）的能力，以便受害者的内存访问时间更准确地揭示它正在访问的数据; 无论共享的全球状态如何，也存在披露的可能性。 想要举一个假想的例子，想象一下，攻击ESXi的VMFS，并使虚拟卷的一部分引用相同的物理磁盘地址，或者使得内存膨胀系统的攻击相信某些内存可以被共享，而实际上它应该是私有的（这与使用免费或双重分配漏洞的工作非常相似）。 考虑虚拟机pipe理程序忽略但允许访问的假设CPU MSR（型号特定的寄存器） 这可以用来在虚拟机之间传递数据，打破虚拟机pipe理程序应该提供的隔离。 还要考虑使用压缩的可能性，以便虚拟磁盘的重复组件只能存储一次 – 某些configuration中可能存在（非常困难的）辅助通道，攻击者可以通过写入其自身并观察来辨别其他虚拟磁盘的内容pipe理程序的function 当然，pipe理程序应该防范这一点，假设的例子将是关键的安全漏洞，但有时候这些东西会漏掉。
• 直接攻击其他虚拟机 。 如果受害者虚拟机有近端主机，则可以利用宽松的访问控制或有意的虚拟机间通信，具体取决于主机的configuration方式以及部署访问控制时做出的假设。 这只是有点相关，但它确实提到。

随着时间的推移，特定的攻击将会出现并被打上补丁，因此将某种特定的机制分类为可利用的，只能在实验室条件下被利用，或者是无法被利用的，是不可行的。 正如你所看到的那样，攻击往往涉及到困难，但在特定时间哪些是可行的，是一个变化很快的事情，你需要做好准备。

也就是说，我上面提到的vector（在某些情况下可能是最后一个例外）根本不存在于裸机环境中。 所以，是的，鉴于安全是为了防止你不知道的漏洞，而且这些漏洞并非公开披露的漏洞，你可以通过运行裸机或者以至less在虚拟机pipe理程序没有托pipe所有和各种虚拟机的环境中。

一般而言，安全应用程序编程的有效策略是假devise算机上运行的其他进程可能受到攻击者控制或恶意攻击，并使用漏洞感知编程技术，即使您认为自己不保证此类进程存在于您的虚拟机中。 但是，特别是前两个类别，请记住先触摸硬件的人先胜出。

理论上，没有。 虚拟机pipe理程序的重点在于将虚拟机彼此隔离。

在实践中，各种虚拟机pipe理程序中都存在（也可能是将来）安全漏洞，这可能会允许一个虚拟机影响同一主机上的虚拟机pipe理程序或其他虚拟机。 诸如sVirt （用于KVM / QEMU）的安全措施旨在解决这个问题。

编辑：我认为这个话题是在几个月前完成的，但是它刚刚复活，现在OP要求更多“真实的事实，引用的研究报告”等等，所以我想到了什么。

这种性质的利用是：

1. 罕见
2. 本质上是敏感的，因此不能公开分享，在这个网站上的任何人知道他们之前，这些漏洞会被供应商打上补丁
3. 复杂，并会因供应商而异

我们不能说破解虚拟机pipe理程序并访问其他虚拟机是不可能的。 我们也不能量化那里有多less风险，除非这个经验告诉我们这个风险很低，因为你不会发现许多利用pipe理程序漏洞的攻击事件。

这里有一个相反的有趣的文章 ，表明已经进行了一些以hypervisor为基础的攻击。

然而，现在比以往任何时候更依赖于虚拟机pipe理程序的技术，比起其他任何types的漏洞，这些漏洞都会被修补和防范得更加紧迫。

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

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

注意“转义pipe理程序”漏洞的测量百分比，这听起来很可怕。 当然，你需要阅读报告的其余部分，因为有更多的数据用于备份索赔。

这是一个关于Playstation 3虚拟机pipe理程序可能被利用的故事，这很有趣。 也许不会影响你的业务，除非你的业务是索尼，在这种情况下，这是非常有影响力的。

这里有一篇来自VMware的Eric Horschman的精彩文章，他对我来说听起来像是一个十几岁的小孩，但是它仍然是一篇很好的文章。 在这篇文章中，你会发现这样的花絮：

微软玻璃屋的居民还有另外一些石头可以折腾我们。 微软指出，CVE-2009-1244是ESX和ESXi中的客户漏洞漏洞的一个例子。 嘉宾突破性的利用是严肃的事情，但微软再一次歪曲事实。 VMware迅速做出了回应，为我们的产品中的漏洞进行了修补，而且ESX受到的影响远远小于Microsoft会让您相信：

在竞争者之间Qu </s>。 但是他可能在整篇文章中说的最清晰的是：

事实是，任何企业软件的漏洞和漏洞都不会完全消失。

OpenBSD项目的Theo de Raddt ：

如果您认为全球范围内不能编写操作系统或应用程序而没有安全漏洞的软件工程师，他们可能会转身，突然编写没有安全漏洞的虚拟化层，如果不是愚蠢的话，您绝对会被迷惑。

有点煽动性，但他的观点很好。 理论上讲，虚拟化应该提供虚拟机与主机之间的完全隔离。 在实践中，偶尔存在一些安全漏洞，使得高级攻击者可以绕过这些防护措施，进入其他虚拟机，甚至更糟的是他们的主机（见“对敌对虚拟化环境主机的安全暴露的实证研究” ）。 Ryan Ries提到这类漏洞是非常罕见的（这并不意味着它们不存在），并且通常不会被供应商透露，但它们确实存在。

如果您担心这种攻击的可能性（我认为在某种程度上应该是这样），我build议您不要在单个虚拟主机或虚拟主机群集上混用安全区域。 例如，您将拥有DMZ虚拟机专用的两个主机虚拟主机群集，一个专用于中间件的群集和一个专用于受保护资产的群集。 通过这种方式，如果攻击者利用这种方式来攻击其他虚拟机，或者pipe理程序本身更糟糕，那么您的安全模型仍然完好无损。