SSB(speculative store bypass)分析和防护措施 -CVE-2018-3639

在2018年1月，微软发布了涉及投机执行方渠道（称为Specter和Meltdown）的新类硬件漏洞的安全更新。在本博客文章中，我们将提供技术分析，推测性执行侧通道漏洞的另一个子类，称为Speculative Store Bypass（SSB），已被分配CVE-2018-3639。SSB由Microsoft安全响应中心（MSRC）的Ken Johnson和Google Project Zero（GPZ）的Jann Horn（@tehjh）独立发现。

这篇文章主要面向对SSB技术分析感兴趣的安全研究人员和工程师，以及与之相关的缓解措施。如果您对更一般的指导感兴趣，请参阅我们的Speculative Store Bypass的建议以及针对Windows Server，Windows Client和Microsoft云服务的知识库文章。

TL;DR

在深入了解技术细节之前，下面简要总结受SSB影响的CPU，Microsoft对风险的评估以及迄今为止确定的缓解措施。

微软正在与CPU制造商合作，评估可用于解决CVE-2018-3639的新硬件功能的可用性和准备情况。在某些情况下，这些功能需要安装微码或固件更新。微软计划在未来的Windows更新中提供利用新硬件功能的缓解措施。

Speculative Store Bypass (SSB)概述

在我们关于减轻投机执行侧通道硬件漏洞的博客文章中，我们描述了三个可用于为推测性执行侧通道创建条件的推测原语。这三个基元提供了沿非架构路径进入投机执行的基本方法，包括条件分支错误预测，间接分支错误预测和异常传递或延期。Speculative Store Bypass (SSB)属于我们称为内存访问错误预测的推测原语的新类别。

SSB出现是由于CPU优化，可以允许潜在的依赖加载指令在旧商店之前被推测性地执行。具体而言，如果预测负载不依赖于先前的存储，则可以在存储之前推测性地执行负载。如果预测不正确，这可能导致读取过期的数据，并可能在推测期间将该数据转发到其他相关的微操作上。这可能会引发投机执行方面的渠道和敏感信息的披露。

为了说明这可能如何发生，可以考虑下面的简单例子。在这个例子中，假设RDI和RSI等于体系结构路径上的相同地址。

01：88040F mov [rdi + rcx]，al
02：4C0FB6040E movzx r8，byte [rsi + rcx]
03：49C1E00C shl r8，字节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最终会检测到错误预测并丢弃计算出的状态，

为了解释这个问题，这个例子被简化了，但是可以想象这个概念可能发生的概括。例如，类似的序列可能存在于SSB可能引起推测性越界读取，类型混淆，间接分支等情况下。我们修订了我们针对推测性执行端通道的C ++开发人员指南，以包含可能产生CVE-2018-3639实例的代码模式和条件的其他示例。实际上，找到CVE-2018-3639的可利用实例需要攻击者识别一个指令序列，其中：

1.该序列可通过信任边界到达，例如用户模式下的攻击者可以通过系统调用以内核模式触发序列。
2.该序列包含一个架构上依赖于先前存储的加载指令。
3.由加载指令读取的陈旧数据是敏感的，并且以可在非架构路径上创建侧通道的方式使用，例如数据馈送公开小工具。
4.在构成公开小工具的负载和依赖指令被推测执行之前，存储指令不执行。

虽然我们对这个新漏洞类的研究仍在进行，但我们尚未确定满足上述所有条件的指令序列，而且我们目前还没有意识到在我们的软件中存在任何CVE-2018-3639可利用的实例。

在即时（Just-in-Time，JIT）编译器的情况下，例如现代Web浏览器使用的JavaScript JIT，攻击者可能会提供产生满足上述条件的本机代码的JavaScript。但是，Microsoft Edge，Internet Explorer和其他主流浏览器已采取措施降低定时器的精度，以增加成功创建副通道的难度。

Speculative Store Bypass (SSB)）的缓解措施

有多种适用于SSB的缓解措施。在我们以前的博客文章减轻投机性执行端的通道，我们的特点软件的安全模型通常可以在风险和各种策略以减轻投机执行侧通道。我们将重新使用该帖子中以前建立的术语来构建SSB可用的缓解选项。

与软件安全模型的相关性

下表总结了SSB与软件安全模型通常关心的各种设备内攻击情况的潜在相关性。与CVE-2017-5753（幽灵变体1），SSB是理论上适用于由橙色作为指示的每个攻击场景（灰色单元格表示不适用）。

防止涉及SSB的投机技巧

正如我们在过去所指出的那样，减轻漏洞的最好方法之一就是尽可能地解决问题，尽可能接近根本原因。在SSB的情况下，有一些技术可以用来防止依赖SSB作为推测原语的猜测技术。

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

与CVE-2017-5753（Specter变体1）一样，可以通过使用架构定义的指令序列化执行来缓解SSB，从而充当推测障碍。对于SSB，可以在存储指令和加载之间插入序列化指令（例如ARM上的x86 / x64和SSBB上的LFENCE），并可以在存储之前进行推测性执行。例如，在第2行插入一个LFENCE减轻了这篇文章中简化的例子。有关其他信息，请参阅“ C ++开发人员指导推荐执行端通道”。

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和英特尔已经记录了软件可以用来实现这一目标的新硬件功能。微软正在与AMD，ARM和英特尔合作评估这些功能的可用性和准备情况。在某些情况下，这些功能需要安装微码或固件更新。微软计划在未来的Windows更新中提供利用新硬件功能的缓解措施。

也适用于SSB的一般缓解措施

有一些先前描述的缓解措施也一般适用于SSB。其中包括涉及从记忆中删除敏感内容或删除观察频道的缓解措施。一般而言，针对CVE-2017-5753（Specter variant 1）的这两种策略的缓解技术也适用于SSB。

缓解措施的适用性

这些问题的复杂性使得难以理解缓解措施，推测技术和它们所应用的攻击情景之间的关系。本节提供表格来帮助描述这些关系。以下表格中提到的一些缓解技术在我们之前关于此主题的博客文章中进行了描述。

下面的表格的图例中绿色代表适用，灰色代表不适用

缓解与攻击情景的关系

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

与变体的缓解关系

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

总结

在这篇文章中，我们分析了一类新的推测性执行端通道硬件漏洞，称为投机商店旁路（SSB）。该分析为评估与此类漏洞相关的风险和存在的缓解选项提供了基础。正如我们在上一篇文章中所提到的，对投机执行方面渠道的研究正在进行中，随着我们了解更多，我们将继续发展我们的回应和缓解措施。尽管我们目前评估SSB的风险较低，但我们鼓励研究人员进一步帮助我们理解真实风险，并报告可能存在的CVE-2018-3639可利用实例，这些实例可能是我们的投机执行端渠道奖励计划的一部分。