虚拟机(VM)可以“入侵”在同一物理机上运行的另一个VM吗?


12

问题:

  • 如果某个虚拟机已损坏(被黑客入侵),那么我会对在同一物理计算机上运行的其他虚拟机承担什么风险?
  • 在同一物理主机上运行的虚拟机之间存在什么样的安全问题?
  • 有(您可以列出)这些(潜在)弱点和/或问题吗?

警告:

我知道存在许多虚拟化类型/解决方案,并且可能存在不同的弱点。但是,我主要是在寻找有关虚拟化技术的一般安全问题,而不是特定的供应商错误。

请提供真实的事实,(认真的)研究,有经验的问题或技术说明。请明确点。不要(仅)发表您的意见。

  • 例子:

两年前,我听说可能存在与MMU有关的安全性问题(我认为访问其他计算机的主内存),但是我不知道这是今天的实际威胁,还是只是理论研究学科。

编辑:我还发现,即使GnuPG在另一台 VM上运行,这种“刷新+重新加载”攻击也能够通过利用L3 CPU缓存来检索同一台物理计算机上的GnuPG秘密密钥。此后,已对GnuPG进行了修补。


2
@MichaelHampton(和其他+3000代表)对不起,我不同意结束这个问题。我不是在期待,也不是在寻找辩论来回答这个问题,而只是期待真实的事实,引用的研究,文章或研究论文,分享经验丰富的问题​​,关于隔离的技术性解释等。您认为会发生哪种辩论?我不是在问虚拟化对于安全性是“好”还是“坏”,而我恰恰问:“我要承担什么风险”和“哪些安全问题”!如果您认为问题更具体,请随时编辑我的问题,但请不要禁止它。
Totor

2
我认为这是一个合理的问题。过去一直存在合理的顾虑,因此人们对安全性的担忧是可以预期的。informationweek.com/government/security/...
斯特凡Lasiewski

3
我并不反对重新提出这个问题,但是我认为您可能会在我们的姊妹网站Information Security上获得更好的答案(而且问题太老了,无法迁移)。
迈克尔·汉普顿

@MichaelHampton是的,我会考虑在这里问是否没有足够好的答案。谢谢。
Totor

Answers:


9

如果可以利用,当然可以利用在同一硬件上运行的另一个VM。另外,可以存在一个。您的问题引述了一些最近的工作,其中有一项工作。我不会在这里分享任何特定的漏洞利用或PoC,但我会很高兴地说出它们的制作方法。

在这种情况下使用的漏洞利用程序自然不同于在您要在其上利用服务的同一台计算机上运行时起作用的漏洞利用程序,由于隔离度的增加,它们往往会变得更加困难。但是,可以用来完成这种利用的一些常规方法包括:

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

随着时间的流逝,特定的攻击将会出现并进行修补,因此将某种特定的机制归类为可利用,仅在实验室条件下可利用或无法利用是永远无效的。如您所见,攻击往往涉及且困难,但是在特定时间可行的攻击却会迅速变化,您需要做好准备。

就是说,我上面提到的向量(在某些情况下可能是最后一个向量除外)在裸机环境中根本不存在。因此,是的,鉴于安全性就是要防范您知道的漏洞以及尚未公开使用的漏洞,以及公开披露的漏洞,因此,您可以通过裸机运行或在至少在虚拟机管理程序无法托管所有虚拟机的环境中。

通常,安全的应用程序编程的有效策略是,假设计算机上正在运行其他进程,这些进程可能是攻击者控制的或恶意的,并且使用有漏洞利用的编程技术,即使您认为自己没有其他理由也无法确保这样的进程存在于您的VM中。但是,尤其是对于前两个类别,请记住,首先接触硬件的人会获胜。


最佳答案,谢谢!您能否提供更多有关“主机体系结构”弱点的不同类型的详细信息?另外,我不是要寻找特定的漏洞利用程序,而是相应地编辑了我的问题(只是想避免投机取巧)。
Totor

嘿,当然。请稍等一下,我会详细说明。
Falcon Momot

并做了。它确实比我想要的更多地偏离了假设,但这应该是说明性的。
Falcon Momot 2013年

特别是,SSL / SSH密钥窃取攻击是对同一主机中的VM guest虚拟机起作用,因为它是对CPU调度程序的直接攻击。
joshudson

13

从理论上讲,没有。系统管理程序的全部目的是将虚拟机彼此隔离。

实际上,各种虚拟机管理程序中存在(并且将来可能)存在安全漏洞,这些漏洞可能允许一个虚拟机影响同一主机上的虚拟机管理程序或其他虚拟机。诸如sVirt(针对KVM / QEMU)的安全措施旨在解决此问题。


@RyanRies(和KCEMichaelHampton)谢谢你对那些漂亮的答案,但你能更具体和技术性的问题可能会再次关闭,如果没有“真正的事实,援引研究,研究论文,遇到的问题或技术说明”,但大多是投机性或含糊的答案/建议。我已经相应地编辑了我的问题。
Totor

8

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

这种性质的漏洞有:

  1. 罕见
  2. 本质上是敏感的,因此不公开共享,并且当它们被共享时,漏洞将由供应商修补,此站点上的任何人都不会知道它们
  3. 复杂,因供应商而异

我们不能说黑掉管理程序并获得对其他VM的访问是不可能的。我们也无法量化有多少风险,除了经验表明我们的风险非常低之外,考虑到您不会发现许多利用虚拟机管理程序漏洞的攻击故事。

相反,这是一条有趣的文章,它表明已经进行了多种基于管理程序的攻击。

但是,由于现在比以往任何时候都更加依赖虚拟机管理程序的技术,这种漏洞利用将比几乎任何其他类型的漏洞利用更为紧迫地加以修补和防范。

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

(请在新标签页中打开此图片以查看其完整尺寸。)

IBM X-Force 2010年中期趋势和风险报告。

请注意,“逃脱到虚拟机管理程序”漏洞的度量百分比对我来说听起来很吓人。自然,您希望阅读报告的其余部分,因为其中包含大量数据以备份索赔。

是一个关于在Playstation 3虚拟机管理程序上进行的可能利用的故事,这很有趣。也许对您的业务影响不大,除非您的业务是索尼,在这种情况下影响非常大

是来自VMware的Eric Horschman的精彩文章,在他看来对我来说听起来像是一个十几岁的孩子都在学习Micro-oft,但它仍然是一篇不错的文章。在本文中,您会发现如下花絮:

微软玻璃屋里的居民还有其他石头扔给我们。Microsoft指出CVE-2009-1244作为ESX和ESXi中的来宾突破漏洞的示例。来宾突破漏洞利用是一项严肃的业务,但是,微软再次歪曲了事实。VMware迅速做出反应,在我们的产品中修复了该漏洞,与Microsoft相比,ESX受到的影响要小得多,从而使您相信:

在竞争者之间不休。但他在整篇文章中所说的最清醒的话可能是:

事实是,对于任何企业软件来说,漏洞和利用永远不会完全消失。


请问百分比在图片上是什么意思?
Totor

它是一个直方图,指示每个目标类别中按类型发现的外伤百分比。换句话说,“工作站百分比”第一行中的30.8%意味着,IBM X-Force发现影响工作站虚拟化软件的30.8%的外伤直接攻击了主机OS​​(例如,工作站受到了攻击,几乎没有或几乎没有)与虚拟化软件或虚拟机有关)。等等。
Falcon Momot

6

OpenBSD项目永远引用的 Theo de Raddt

如果您认为全世界范围内无法编写没有安全漏洞的操作系统或应用程序的软件工程师,可以转而突然编写没有安全漏洞的虚拟化层,那绝对是您的愚蠢之举,即使不是那么愚蠢。


有点发炎,但他的观点是正确的。从理论上讲,虚拟化应该在虚拟机及其主机之间提供完全隔离。在实践中,偶尔会有安全漏洞,这些漏洞使高级攻击者可以规避这些保护并获得对其他虚拟机的访问权限,甚至使其主机更糟(请参阅对敌对虚拟化环境的主机安全暴露的经验研究)。正如Ryan Ries所提到的那样,此类漏洞非常罕见(这并不意味着它们不存在),并且通常不会被供应商披露,但是它们确实存在。

如果您担心此类攻击的可能性(我认为应该在某种程度上应该如此),建议您不要在单个虚拟主机或虚拟主机群集上混合使用安全区域。例如,您将拥有专用于DMZ虚拟机的两台主机虚拟主机群集,适用于中间件的专用群集以及适用于受保护资产的专用群集。如果利用漏洞利用这种方式,则攻击者可以利用它来破坏其他虚拟机,或者更糟的是,虚拟机管理程序本身仍会保留您的安全模型。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.