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