Amazon EC2防御L1TF重加载攻击 | AWS安全博客

运行在AWS Nitro系统和Nitro Hypervisor上的AWS客户客户数据不受新型攻击“L1TF Reloaded”的影响。AWS客户无需采取额外措施；但AWS继续建议客户按照AWS公开文档中的说明，使用实例、飞地或功能边界隔离其工作负载。AWS Nitro系统和Nitro Hypervisor旨在帮助防御此类攻击。

一篇题为《Rain: 利用旧漏洞从公共云临时泄漏数据》的研究论文及其演示《现实世界中的Spectre：利用CPU漏洞从云中泄漏您的私有数据》展示了L1TF重加载攻击，该攻击将半Spectre小工具与L1终端故障（L1TF）结合以泄漏客户数据。虽然此攻击可以成功从上游Linux/基于内核的虚拟机（KVM）和其他云提供商泄漏客户数据，但它不影响运行在AWS Nitro系统和Nitro Hypervisor上的AWS客户数据。

Nitro Hypervisor对L1TF重加载的防护不是特定补丁或反应性缓解的结果，而是由于AWS主动的安全方法。Nitro Hypervisor的基本安全设计原则——特别是通过广泛使用独占页框所有权（XFPO）概念（在某些上下文中称为进程本地内存）实现秘密隐藏——提供了对此类攻击的强健防护。L1TF重加载代表了瞬态执行攻击的一种创新方法，展示了威胁行为者如何组合看似已缓解的漏洞以创建超越其部分总和的新攻击。该研究令人印象深刻，并构建了具有实际适用性的多层端到端利用。AWS赞助了部分工作，并感谢研究人员的合作和协调披露。本文的其余部分是对已发表研究的深入探讨。

Nitro Hypervisor：为安全而构建

Nitro Hypervisor是AWS Nitro系统的基础组件，从设计之初就将安全作为主要考虑因素。与从通用操作系统演变而来的传统虚拟机监控程序不同，基于Linux/基于内核的虚拟机（KVM）的Nitro Hypervisor被有意最小化并专门构建，仅包含执行其指定功能所需的能力。

Nitro Hypervisor的职责被刻意限制：它从Nitro控制器接收虚拟机（VM）管理请求，使用硬件虚拟化功能分区内存和CPU资源，并将PCIe设备（包括由Nitro硬件提供的物理功能（PF）和单根I/O虚拟化（SR-IOV）虚拟功能（VF）（如用于EBS和实例存储的NVMe，以及用于网络的弹性网络适配器）和第三方设备（GPU）分配给VM。关键的是，Nitro Hypervisor排除了传统虚拟机监控程序中存在的整个功能类别。没有网络堆栈，没有通用文件系统实现，没有外围设备驱动程序支持，没有shell，也没有交互式访问模式。这种对非必要功能的细致排除有助于避免影响其他虚拟机监控程序的整个问题类别和攻击向量，如远程网络攻击或基于驱动程序的权限提升。

理解瞬态执行漏洞

要理解为什么Nitro Hypervisor的防御对L1TF重加载有效，首先需要理解2018年出现的瞬态执行漏洞的基础知识。现代CPU实现乱序和基于预测的推测执行，通过在需要之前或CPU知道是否应该执行操作之前执行操作来优化性能。当预测错误或CPU遇到执行故障时，CPU最终会检测到这些错误并回滚所有推测计算的更改到架构状态。然而，这些“瞬态执行”的痕迹在微架构状态中仍然可检测，如被推测加载到CPU缓存中的数据，为通过侧信道攻击的数据泄漏创造了机会。

半Spectre小工具：不完整但危险的代码模式

虽然传统的Spectre攻击需要完整的小工具，既能访问秘密数据又能通过侧信道传输它，但研究人员已经识别出一类较弱的小工具，称为“半Spectre小工具”。这些是不完整的类似Spectre的代码模式，执行推测性的越界内存访问，但缺乏使它们立即可 exploitable 的传输组件。

经典的Spectre v1小工具包含两个关键元素：首先，一个推测访问加载秘密数据（如x = A[index]，其中index越界），其次，一个通过侧信道泄漏数据的传输机制（如y = B[64 * x]，基于秘密值创建缓存模式）。半Spectre小工具仅包含第一个元素——推测访问——而没有传输组件。

由于半Spectre小工具单独看起来无害，它们常见于整个软件中，包括虚拟机监控程序。这些小工具通常源于数组索引操作，其中发生边界检查，但瞬态执行窗口允许在边界检查解析之前进行越界访问。小工具可以是绝对的（直接提供要访问的地址）或相对的（控制从基地址的偏移），相对小工具由于典型的数组索引模式更常见。L1TF重加载的关键洞察是，半Spectre小工具虽然单独无害，但当与像L1TF这样的其他漏洞结合时变得危险。威胁行为者可以触发虚拟机监控程序中的半Spectre小工具，以推测性地将任意数据加载到L1数据缓存中，然后使用L1TF提取该缓存数据——有效地将“无害”的半Spectre小工具转变为完整的小工具。

Intel L1TF：利用推测地址转换

L1终端故障（L1TF）于2018年1月发现并于2018年8月披露，代表了一种重要的瞬态执行漏洞类型，影响直至Coffee Lake的Intel处理器。这些处理器用于一些第5代EC2实例系列和所有较旧的实例类型。L1TF在瞬态执行期间访问无效页表条目时利用错误的地址转换。在正常操作下，当CPU遇到存在位清除或保留位设置的页表条目（PTE）时，地址转换应立即停止。然而，在瞬态执行期间，受L1TF影响的Intel处理器忽略这些无效页表状态并使用部分转换的地址。如果目标数据存在于L1数据缓存中，CPU将推测性地加载它并使其可用于后续指令，即使访问应被阻止。这种行为在虚拟化环境中尤其成问题。恶意客户操作系统可以故意清除其自身页表中的存在位以触发终端故障。当这种情况发生时，CPU跳过正常的主机地址转换过程并将客户物理地址直接传递给L1数据缓存。这允许威胁行为者潜在地读取系统上的任何缓存物理内存，无论所有权或权限边界如何。对于受影响的处理器，全面的软件缓解需要昂贵的措施，如禁用同时多线程（SMT），在每次上下文切换时刷新L1数据缓存，或完全禁用扩展页表（EPT）——性能成本如此显著，以至于许多系统仅实施部分缓解。

L1TF重加载攻击：利用Spectre利用缓解差距

该研究论文展示了威胁行为者如何将半Spectre小工具与L1TF结合，以创建针对缺乏先前概述的缓解措施完整实现的虚拟机监控程序的强大攻击向量。该攻击表明，如果以新颖方式组合，被认为单独缓解的漏洞仍然可以被利用。L1TF重加载通过利用以下事实工作：虽然像L1数据缓存刷新和核心调度这样的L1TF缓解措施有助于防止客户到客户的攻击，但它们不能完全缓解客户到主机的攻击。该攻击在共享SMT核心中的L1数据缓存的逻辑核心上操作。在一个逻辑核心上，威胁行为者触发半Spectre小工具。通过错误训练分支预测器，威胁行为者导致虚拟机监控程序推测性地访问越界内存，将敏感数据加载到共享的L1数据缓存中。同时，在另一个逻辑核心上，威胁行为者使用L1TF提取缓存数据。虽然其他研究论文已经证明了L1TF利用，但该研究论文已成功演示了对上游Linux/KVM和其他云提供商的多层端到端攻击。作者能够使用现有的半Spectre小工具，打破主机内核地址空间布局随机化（KASLR），获得主机地址转换能力，找到主机上运行的所有进程，识别受害者VM，打破客户KASLR，获得客户地址转换能力，识别受害者VM中的init进程，枚举init进程的子进程，识别nginx Web服务器进程，定位客户进程堆中的私有TLS证书，并最终泄漏私有TLS证书。然而，当他们在AWS实例上尝试相同的攻击时，他们遇到了一个关键限制：虽然他们可以泄漏一些非敏感主机数据，但由于他们描述的“虚拟机监控程序中的未记录防御，将受害者数据从其取消映射”，他们无法访问客户数据。这种“未记录防御”是Nitro Hypervisor的秘密隐藏实现——一个阻止此类攻击的基本架构决策。

秘密隐藏：重新思考虚拟机监控程序内存架构

传统虚拟机监控程序设计遵循分层权限模型，其中每个更高级别的权限被授予访问所有较低级别内存的权限。在传统系统中，以最高权限级别运行的虚拟机监控程序可以访问所有VM内存，表面上是为了合法的管理目的。然而，这种设计创建了一个漏洞：如果威胁行为者可以诱使虚拟机监控程序推测性地访问客户数据，则该数据变得可通过侧信道攻击提取。Nitro Hypervisor通过称为秘密隐藏的技术采取根本不同的方法。而不是遵循传统模型，其中虚拟机监控程序有权访问所有VM内存（图1），Nitro Hypervisor确保客户数据不存在于虚拟机监控程序的虚拟地址空间中。通过从虚拟机监控程序的虚拟地址空间中删除VM内存页（图2），我们避免了瞬态执行攻击访问客户数据的可能性，即使威胁行为者成功触发虚拟机监控程序内的小工具。

图1：在VM1上下文中未缓解的虚拟机监控程序内存视图

图2：在VM1上下文中Nitro Hypervisor的内存视图。虽然未映射任何客户内存，但只能访问活动客户的状态，其他客户状态保持不可访问。

这种架构决策意味着当在Nitro Hypervisor中发生瞬态执行时——无论是通过L1TF、半Spectre小工具还是其他瞬态执行漏洞——根本没有可泄漏的客户数据，为此类漏洞创建了屏障。Nitro Hypervisor仅保留对其自身数据的访问权限，但客户数据保持隔离和不可访问。虽然我们无法准确预测L1TF重加载，但我们知道瞬态执行漏洞将继续被发现，并构建了深度防御机制，阻止在AWS实例上提取客户数据。这一设计决策是在Nitro Hypervisor开发期间主动做出的，基于我们的威胁模型，该模型明确包括利用虚拟机监控程序的客户到主机攻击。通过假设威胁行为者可能找到方法触发Nitro Hypervisor内的瞬态执行漏洞——无论是通过像L1TF这样的已知漏洞还是未来未知的攻击向量——我们设计了系统以从一开始限制此类攻击的范围。

超越内存：保护客户CPU上下文

当VM被调度和上下文切换时，必须保存和恢复客户CPU上下文信息，如通用和浮点寄存器内容。客户CPU上下文可以包含高度敏感的信息。寄存器可能包含加密密钥、可能击败地址空间布局随机化（ASLR）的内存地址，或应用程序依赖安全的其他秘密。在传统虚拟机监控程序中，客户CPU上下文通常存储在虚拟机监控程序可访问的内存中，创建了另一个瞬态执行攻击的潜在目标。原始XPFO（独占页框所有权）实现确保用户空间或内核——但不是两者——可以访问内存页，并且不保护客户CPU上下文，因为它由内核独占拥有。Nitro Hypervisor通过将客户CPU上下文保存在内存中（也称为进程本地内存）来扩展XPFO概念到客户CPU上下文，该内存仅由进程特定的内核页表条目（PTE）映射，如上图2所示。该内存专门设计为仅可从属于其的进程上下文中的Nitro Hypervisor访问。这确保即使威胁行为者成功触发Nitro Hypervisor内的瞬态执行漏洞，他们也无法从其他客户访问客户CPU上下文。研究人员确认了这种保护，指出AWS威胁模型考虑了客户到主机的攻击，并且秘密隐藏与现有的L1数据缓存刷新和核心调度结合，阻止了他们泄漏客户数据。这种全面的秘密隐藏方法展示了Nitro系统的深度防御哲学：而不是仅保护已知攻击向量，AWS系统地识别和保护潜在的客户数据泄漏源，包括VM内存和客户CPU上下文。

将秘密隐藏原则应用于Xen

大多数AWS Xen实例现在运行在AWS Nitro系统上，因此得益于Xen-on-Nitro的Nitro Hypervisor优势。对于我们运行在AWS Xen Hypervisor上的实例系列组合，我们已经实施了类似的秘密隐藏原则，以提供对瞬态执行攻击的防护。

深度防御：Nitro Hypervisor经过验证的安全模型

L1TF重加载代表了我们对如何组合看似已缓解的漏洞以创建新攻击向量的理解的重要进步。Rain论文的研究人员展示了L1TF和半Spectre小工具如何协同工作以从虚拟机监控程序泄漏客户数据。我们很高兴支持他们的工作并与他们合作。Nitro Hypervisor对L1TF重加载的防护不是特定补丁或反应性缓解的结果，而是由于AWS深入投资于保护多租户云环境免受复杂对手的侵害。这项研究增强了我们对Nitro系统安全模型对抗已知和未知攻击向量的信心。AWS的主动安全方法包括从设计之初就采用深度防御原则设计系统。威胁格局将继续演变，同时，内置到Nitro Hypervisor和我们其他产品和服务中的深度防御机制将继续帮助保护AWS客户免受复杂攻击，同时保持他们依赖的性能和功能。

如果您对此帖子有疑问或反馈，请联系AWS支持。