[论文解读] Speculative Buffer Overflows: Attacks and Defenses

Vladimir Kiriansky, Carl A. Waldspurger|arXiv (Cornell University)|Jul 10, 2018

Security and Verification in Computing参考文献 22被引用 127

一句话总结

该论文介绍了推测性缓冲区溢出（Spectre1.1 和 Spectre1.2），分析它们的硬件/软件机制，并提出 SLoth 硬件缓解方案来限制推测性存储到加载转发，以及手动的软件防御。

ABSTRACT

Practical attacks that exploit speculative execution can leak confidential information via microarchitectural side channels. The recently-demonstrated Spectre attacks leverage speculative loads which circumvent access checks to read memory-resident secrets, transmitting them to an attacker using cache timing or other covert communication channels. We introduce Spectre1.1, a new Spectre-v1 variant that leverages speculative stores to create speculative buffer overflows. Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can bypass some Spectre-v1 mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can bypass fence instructions and all other software mitigations for previous speculative-execution attacks. It is easy to construct return-oriented-programming (ROP) gadgets that can be used to build alternative attack payloads. We also present Spectre1.2: on CPUs that do not enforce read/write protections, speculative stores can overwrite read-only data and code pointers to breach sandboxes. We highlight new risks posed by these vulnerabilities, discuss possible software mitigations, and sketch microarchitectural mechanisms that could serve as hardware defenses. We have not yet evaluated the performance impact of our proposed software and hardware mitigations. We describe the salient vulnerability features and additional hypothetical attack scenarios only to the detail necessary to guide hardware and software vendors in threat analysis and mitigations. We advise users to refer to more user-friendly vendor recommendations for mitigations against speculative buffer overflows or available patches.

研究动机与目标

• 将推测性缓冲区溢出作为在推测执行期间打破内存安全的攻击来引入。
• 分析使这些攻击成为可能的硬件特性，以指导缓解措施。
• 提出软件缓解和硬件解决方案（SLoth）来防御推测性缓冲区溢出。
• 讨论威胁模型和潜在载荷，以为分层防御策略提供信息。

提出的方法

• 描述 Spectre1.1 和 Spectre1.2 的攻击机制及所需的推测执行窗口。
• 分析存储转加载转发以及数据/TLB 预测作为基础硬件特征。
• 回顾并将经典缓冲区溢出缓解方法应用于推测性场景（例如推测封锁、屏蔽和 TOCTOU 防御）。
• 提出 SLoth 系列（Store-to-Load Blocking、Lazy Forwarding、Frozen Forwarding）作为硬件缓解措施。
• 概述风险场景，包括幽灵/光环及潜在载荷，以指导威胁分析和缓解设计。

实验结果

研究问题

• RQ1 Spectre1.1 和 Spectre1.2 除了 Spectre1.0 能带来哪些新的能力？
• RQ2 存储缓冲区、MSHR 和 TLB 推测等硬件结构如何被推测性缓冲区溢出利用？
• RQ3 哪些软件和硬件缓解措施能在不造成过高性能损失的情况下有效防止推测性缓冲区溢出？
• RQ4 由推测性缓冲区溢出漏洞带来的现实威胁模型和潜在攻击载荷是什么？

主要发现

• Spectre1.1 通过推测性存储实现任意推测性写入，可能绕过先前的缓解措施。
• Spectre1.2 通过利用对保护的惰性执行来覆盖只读数据和代码指针，破坏沙箱。
• 存在手动和粗粒度的缓解措施，但代价通常较高或不完整；文中讨论了与数据相关的精确屏蔽和按流防御。
• 提出一组硬件缓解措施（SLoth 家族），以在不同复杂度和性能影响下限制存储到加载的转发。
• 攻击载荷讨论表明在推测执行威胁下存在本地和远程的机密性、完整性和可用性风险。
• 论文强调需要纵深防御和在缓解措施进行性能评估前的厂商指导。