分析与缓解投机存储旁路（CVE-2018-3639）

作者：Security Research & Defense
日期：2018年5月21日
阅读时间：9分钟

2018年1月，微软发布了一份公告和安全更新，针对涉及投机执行侧信道的新一类硬件漏洞（称为Spectre和Meltdown）。在本博客文章中，我们将对投机执行侧信道漏洞的一个额外子类——投机存储旁路（SSB，分配了CVE-2018-3639）——进行技术分析。SSB由微软安全响应中心（MSRC）的Ken Johnson和Google Project Zero（GPZ）的Jann Horn（@tehjh）独立发现。

本文主要面向对SSB技术分析及相关缓解措施感兴趣的安全研究人员和工程师。如果您需要更一般的指导，请参考我们的投机存储旁路公告和Windows Server、Windows客户端及微软云服务的知识库文章。

请注意，本文信息截至发布日期有效。

摘要

在深入技术细节之前，以下是受SSB影响的CPU简要总结、微软的风险评估以及目前已识别的缓解措施。

• 受影响范围？
  AMD、ARM和Intel CPU在不同程度上受CVE-2018-3639影响。

• 风险如何？
  微软目前评估CVE-2018-3639对客户的风险为低。我们目前未在软件中发现任何可 exploitable 的此漏洞类实例，但我们将继续调查，并鼓励研究人员通过我们的投机执行侧信道赏金计划发现和报告任何可 exploitable 的CVE-2018-3639实例。随着对风险理解的演变，我们将调整CVE-2018-3639的缓解策略。

• 缓解措施是什么？
  微软已作为对Spectre和Meltdown响应的一部分发布了缓解措施，这些措施在某些场景下适用于CVE-2018-3639，例如减少Microsoft Edge和Internet Explorer中的计时器精度。软件开发者可以通过引入投机屏障指令（如微软的C++开发者指南中所述）来 addressing 个别CVE-2018-3639实例。微软正与CPU制造商合作评估可用于解决CVE-2018-3639的新硬件特性的可用性和准备情况。在某些情况下，这些特性需要安装微码或固件更新。微软计划在未来的Windows更新中提供利用新硬件特性的缓解措施。

投机存储旁路（SSB）概述

在我们关于缓解投机执行侧信道硬件漏洞的博客文章中，我们描述了三种可用于创建投机执行侧信道条件的投机原语。这三种原语提供了沿非架构路径进入投机执行的基本方法，包括条件分支误预测、间接分支误预测以及异常交付或延迟。投机存储旁路（SSB）属于一种新的投机原语类别，我们称之为内存访问误预测。

SSB源于一种CPU优化，该优化允许可能依赖的加载指令在较旧的存储之前投机执行。具体来说，如果加载被预测为不依赖于先前的存储，则加载可以在存储之前投机执行。如果预测错误，这可能导致加载读取陈旧数据，并在投机期间将该数据转发给其他依赖的微操作。这可能潜在地导致投机执行侧信道和敏感信息的泄露。

为了说明这可能如何发生，考虑以下简单示例可能有所帮助。在此示例中，假设RDI和RSI在架构路径上等于同一地址。

1
2
3
4

01: 88040F            mov [rdi+rcx],al
02: 4C0FB6040E        movzx r8,byte [rsi+rcx]
03: 49C1E00C          shl r8,byte 0xc
04: 428B0402          mov eax,[rdx+r8]

在此示例中，第1行的MOV指令可能需要额外时间执行（例如，如果RDI+RCX地址表达式的计算正在等待先前指令执行）。如果发生这种情况，CPU可能预测MOVZX不依赖于MOV，并可能在执行存储的MOV之前投机执行它。这可能导致从RSI+RCX位置的内存中加载陈旧数据到R8，并馈送给第4行的依赖加载。如果R8中的字节值是敏感的，则可能通过侧信道（如利用基于缓存的披露原语，如FLUSH+RELOAD（如果RDX引用共享内存）或PRIME+PROBE）观察到。CPU最终将检测到误预测并丢弃计算的状态，但投机期间访问的数据可能已在缓存中创建了残留的副作用，这些副作用可以被测量以推断加载到R8的值。

此示例为解释问题而简化，但可以想象可能发生此概念的泛化。例如，可能存在类似序列，其中SSB可能导致投机越界读取、类型混淆、间接分支等。我们已修订了投机执行侧信道的C++开发者指南，以包括可能导致CVE-2018-3639实例的代码模式和条件的额外示例。在实践中，找到可 exploitable 的CVE-2018-3639实例需要攻击者识别满足以下条件的指令序列：

• 序列可通过信任边界访问，例如用户模式攻击者可以通过系统调用触发内核模式中的序列。
• 序列包含在架构上依赖于先前存储的加载指令。
• 加载指令读取的陈旧数据是敏感的，并以可以在非架构路径上创建侧信道的方式使用，例如数据馈送披露小工具。
• 存储指令在加载之前未执行，且组成披露小工具的依赖指令被投机执行。

尽管我们对这一新漏洞类的研究仍在进行中，但我们尚未识别满足所有上述条件的指令序列，且目前未在软件中发现任何可 exploitable 的CVE-2018-3639实例。

在即时（JIT）编译器（如现代Web浏览器使用的JavaScript JIT）的情况下，攻击者可能提供生成满足上述条件的本机代码的JavaScript。然而，Microsoft Edge、Internet Explorer和其他主要浏览器已采取措施减少计时器精度，以增加成功创建侧信道的难度。

投机存储旁路（SSB）的缓解措施

有多种适用于SSB的缓解措施。在我们先前关于缓解投机执行侧信道的博客文章中，我们描述了通常可能面临风险的软件安全模型以及缓解投机执行侧信道的各种策略。我们将重用该文章中建立的术语来框架SSB可用的缓解选项。

与软件安全模型的相关性

下表总结了SSB与软件安全模型通常关注的各类设备内攻击场景的潜在相关性。与CVE-2017-5753（Spectre变体1）一样，SSB理论上适用于每个攻击场景，如橙色单元格所示（灰色单元格表示不适用）。

防止涉及SSB的投机技术

正如我们过去所指出的，缓解漏洞的最佳方法之一是尽可能接近根本原因地解决问题。在SSB的情况下，有几种技术可用于防止依赖SSB作为投机原语的投机技术。

通过序列化指令的投机屏障

与CVE-2017-5753（Spectre变体1）一样，可以通过使用架构上定义为序列化执行的指令来缓解SSB，从而充当投机屏障。在SSB的情况下，可以在存储指令和可能在存储之前投机执行的加载之间插入序列化指令（如x86/x64上的LFENCE和ARM上的SSBB）。例如，在第2行插入LFENCE可以缓解本文中的简化示例。更多信息可在投机执行侧信道的C++开发者指南中找到。

1
2
3
4
5

01: 88040F            mov [rdi+rcx],al
02: 0FAEE8            lfence
03: 4C0FB6040E        movzx r8,byte [rsi+rcx]
04: 49C1E00C          shl r8,byte 0xc
05: 428B0402          mov eax,[rdx+r8]

投机存储旁路禁用（SSBD）

在某些情况下，CPU可以提供抑制投机存储旁路发生的设施，从而为SSB提供分类缓解。AMD、ARM和Intel已记录了可由软件使用的新硬件特性来实现这一点。微软正与AMD、ARM和Intel合作评估这些特性的可用性和准备情况。在某些情况下，这些特性需要安装微码或固件更新。微软计划在未来的Windows更新中提供利用新硬件特性的缓解措施。

一般适用于SSB的缓解措施

有许多先前描述的缓解措施也一般适用于SSB。这些包括涉及从内存中移除敏感内容或移除观察信道的缓解措施。一般来说，对CVE-2017-5753（Spectre变体1）有效的这两种策略的缓解技术也适用于SSB。

缓解措施的适用性

这些问题的复杂性使得理解缓解措施、投机技术和它们适用的攻击场景之间的关系变得困难。本节提供表格以帮助描述这些关系。下表中提到的一些缓解技术在我们先前关于此主题的博客文章中有描述。

图例：

• ✅ 适用
• ❌ 不适用

缓解措施与攻击场景的关系

下表总结了攻击场景与适用缓解措施之间的关系。

缓解措施与变体的关系

下表总结了SSB与Spectre和Meltdown变体之间的关系以及适用缓解措施。

总结

在本文中，我们分析了一种新的投机执行侧信道硬件漏洞类别——投机存储旁路（SSB）。此分析为评估与此类漏洞相关的风险以及存在的缓解选项提供了基础。正如我们在先前文章中所指出的，对投机执行侧信道的研究仍在进行中，随着我们了解更多，我们将继续发展我们的响应和缓解措施。尽管我们目前评估SSB的风险为低，但我们鼓励研究人员帮助进一步了解真实风险，并通过我们的投机执行侧信道赏金计划报告任何可能存在的可 exploitable 的CVE-2018-3639实例。

Matt Miller
微软安全响应中心（MSRC）