如果我们假设我信任我的提供商并且我们不考虑我的环境中可能存在的错误（例如 Heartbleed），我是否可以安全地假设我的 RAM 永远不能被 EC2 或 Digital Ocean 上的其他用户访问。
VPS 上其他用户的 RAM 有多私密？
信息安全
记忆
共享主机
2021-09-05 18:51:50
3个回答
tl; dr：鉴于您陈述的假设，虚拟机 RAM 是相当私有的。
我不是虚拟机安全方面的专家（真正的专家，请纠正这篇文章中的任何错误），但我发现这个问题很有趣，可以做一些谷歌搜索。这是我发现的。
来自 NIST 出版物，标题为 Hypervisor 部署的安全建议：
虚拟化平台中的常见威胁之一是恶意 VM 访问属于其他 VM 的内存区域。这称为 VM Escape 攻击。具有虚拟化扩展的处理器通过诸如直接内存访问 (DMA) 重新映射将 DMA 访问限制为对 VM 有效的内容（即防止 VM 执行超出其分配区域的 DMA）等特性来提供安全性。
这一段是说硬件加速的虚拟化（这几乎是你在 2015 年将遇到的所有虚拟化）可以很好地实施内存访问限制——至少比纯软件虚拟化要好。
NIST 论文继续提出以下建议：
安全建议 HY-SR-6：所有 VM 的组合配置内存与虚拟化主机的 RAM 内存的比例不应该很高。采用的典型比率是 1.5 : 1。换句话说，如果虚拟主机有 64GB 的 RAM，那么在其上运行的所有 VM 的组合配置内存不应超过 96GB。
安全建议 HY-SR-7：管理程序应具有可用的配置选项，以指定每个 VM（需要它）的保证物理 RAM 以及对该值的限制，并指定优先级值以获取所需的 RAM 资源多个虚拟机之间争用的情况。
出于安全和性能原因，流行的虚拟主机（如 EC2 和 DigitalOcean）可能会遵循这些准则。如果他们超卖 RAM，他们的虚拟机将运行得相当缓慢。但是，对于不太受欢迎的 VM 主机，我不知道他们是否遵循了指南。根据客人的工作量，主人可能会发现超卖是有利可图的。
现在请记住，主机绝对可以存储 RAM 的状态，任何允许在主机上执行任意代码的漏洞都可能导致读取任意 VM RAM 内容。
NIST 论文还提出了一个漏洞，其中用于创建虚拟机的图像被破坏，导致 VM 用户启动已经被破坏的实例。Amazon 和 DigitalOcean 也可能会遵循 NIST 的建议——VM 映像必须具有有效的数字签名，并且不能从运行现有实例的机器上修改新实例的映像。再一次，某个大学宿舍的云管理程序可能在图像上没有同等的安全性。
整篇 NIST 论文都值得一读——它不是很长——以下 Stack Exchange 问题也是如此：
tl：博士；在撰写本文时，Docker 风格的容器不如硬件加速的虚拟机管理程序安全。
回应@grawity 我的另一个答案，这个答案涵盖了像 Docker 这样的容器，它们用于以类似于虚拟机的方式运行应用程序，但容器绝对不是虚拟机。
容器和虚拟机有什么区别？这篇Smartbear 文章解释了（重点是我的）：
那么为什么要关心管理程序与容器呢？Bottomley 解释说，Hyper-V、KVM 和 Xen 等管理程序都有一个共同点：“它们基于模拟虚拟硬件。” 这意味着它们在系统要求方面很胖。
[...]
另一方面，容器基于共享操作系统。它们比管理程序更精简、更高效。容器不是虚拟化硬件，而是位于单个 Linux 实例之上。这意味着您可以“留下无用的 99.9% VM 垃圾，为您留下一个包含您的应用程序的小而整洁的胶囊，”Bottomley 说。
正如我在另一个答案中引用的 NIST 所解释的那样，硬件虚拟化具有安全优势。容器平台摆脱了这些好处以换取性能提升。
Docker 项目的创建者 Solomon Hykes在 2014 年夏天在 Hacker News 上写道，Docker 不保证不受信任的访客的安全性：
请记住，此时，我们并不声称 Docker 开箱即用适用于包含具有 root 权限的不受信任的程序。[...] 当我们说 Docker 开箱即用可以安全地包含不受信任的 uid0 程序时，我们会说得很清楚。
根据Docker 安全指南，可以配置各种增强安全性的设置，但安全性仍由软件强制执行。正如我在其他答案中的 NIST 文档所述，硬件加速的虚拟机管理程序使用硬件来防止 VM 逃逸攻击，从而大大减少了恶意访客的攻击面。尽管 Docker 可能具有全面的安全功能，但它只是具有更大的攻击面。
Gartner 2015 年初对 Docker 的分析同意Docker 与传统虚拟机相比的不成熟。
在撰写本文时，我建议有安全意识的人不要与不受信任的容器共享物理主机，也不要在您的物理机器上运行不受信任的容器。也许这在未来会改变。
tl;dr：基于缓存的泄漏 RAM 攻击是可能的。我会小心让一个 VM 花费 100% 的 CPU 时间来使用密钥进行加密。攻击者还可以减慢您的 VM 速度，这可能有助于进行可能的 RAM 泄漏攻击。此外，请注意捕获正在运行的 RAM 的 VM 快照（不过，大多数云服务不会这样做）。
（我知道对同一个问题有三个不同的答案有点荒谬，但它们代表了三种不同的思路，我正在努力将它们组合成一个答案。）
我刚刚看到Thomas H. Ptacek 对 Cryptography Engineering 的评论，他简要提到了对 Amazon EC2 等虚拟化计算云的侧通道攻击。Ptacek 先生没有列出任何来源或给出示例，但这是我从（另外）一个下午在 Google 上学到的东西：
缓存/内存定时攻击
一个4月起中国移动研究院2014纸，演示了在两个虚拟机之间的恶意软件隐蔽通道的创建。其中一个虚拟机是由攻击者创建的，另一个是你的。这要求您的虚拟机已经受到威胁，但它启用了一种非常难以检测的数据泄露方法。您可能正在监视您的虚拟机是否存在恶意出站网络流量……但您可能会找错地方，因为该恶意软件会使用内存总线争用来向攻击者的虚拟机传输高达每秒数百千字节的数据。
伍斯特理工学院 2014 年的一篇论文描述了对 AES 的跨 VM 定时攻击。论文作者煞费苦心地确保他们的攻击在现实的云计算环境中有效，这使得他们的结果相当可怕。作者指出，内存重复数据删除使该漏洞成为可能，这是一种管理程序功能，可通过检测重复页面来减少内存使用量。这对性能很有好处，但是重复数据删除是违反我在其他答案中提到的NIST 指南并过度销售您的内存的一种聪明方法。
Matthew Green对 2012 年描述跨 VM 侧通道攻击的论文进行了出色的分析。这种攻击更具理论性，在实践中更难实施，亚马逊很可能已经缓解了从那时起所涉及的漏洞。
2010 年的一篇论文描述了备份和恢复虚拟机快照会削弱随机数生成器并导致数据泄漏。在这种情况下，它仅适用于具有完整快照的虚拟机来宾，其中包括活动内存。该论文指出，云服务依赖于卷快照，其中仅包括磁盘内容，并且在快照还原时没有削弱随机数生成器。
这篇来自 UCSD 和 MIT CSAIL 的 2009 年论文是云计算中的边信道攻击的早期研究之一。我猜想（但不确定）大多数实际的攻击现在都被阻止了，但是这篇论文是非常出色的阅读，因为它生动地介绍了攻击者的思维方式。
I/O 减速攻击
关于你原来的问题，这些攻击都没有直接泄漏数据。这些攻击背后的想法是让攻击者仅仅降低受害者的虚拟机速度。但是，我怀疑高级对手可能会使用 I/O 减速攻击作为更广泛的 RAM 窃取攻击的一部分。出于这个原因，我选择在这里提及它。关于如何使用 I/O 减速攻击来提供帮助，我有一些想法，但我不想错误地推测。
我发现的两篇最相关的论文是2012 年 12 月的一篇论文，该论文提出了 vExplorer，这是一个“分布式 VM I/O 性能测量和分析框架”，可用于执行基于 I/O 的攻击”，以及乔治华盛顿大学的一篇类似论文描述一个名为 Swiper 的框架。