幽灵漏洞（Spectre）变体1与变体2技术解析
Spectre（变体1）
幽灵漏洞变体1允许程序读取其本无权访问的内存。Spectre V1攻击之所以可行，是因为分支预测和预测执行两种优化的结合。攻击通过欺骗条件分支预测器跳过安全检查，在错误上下文中预测执行指令，再通过缓存计时侧信道观察这些指令的效果。
技术细节
以下通过一个假设示例（可在Web浏览器中通过JavaScript执行）说明攻击步骤：
- 创建两个大型内存分配：
leaker（用于缓存计时侧信道）和reader（用于训练分支预测器）。数组读取有边界检查，合法索引范围为0到255。 - 训练分支预测器：通过重复读取
reader中的合法值，使预测器假设边界检查总是通过。 - 确保
leaker未被缓存。 - 读取
reader的越界元素（称为secret）。由于预测器已训练，此读取会预测性成功，但处理器稍后会发现分支误预测并撤销执行。 - 使用
secret值作为索引读取reader元素（即reader[secret]），这会预测性执行并将该元素缓存。 - 通过测量每个
secret元素的读取时间，确定被缓存的元素索引，即未授权读取的secret值（例如，若reader[42]被缓存，则secret值为42）。 - 重复攻击可读取更多字节，带宽估计为10 KB/s。
图2展示了reader和secret数据在内存中的布局：由于内存线性排列，通过正负索引可访问任何部分，但边界检查应限制访问0到255。若边界检查被绕过（即使通过预测执行），即可未授权访问内存。
影响是什么？
Spectre V1对桌面、笔记本和移动用户影响重大：它允许网站打破Chrome、IE和Firefox等浏览器的安全隔离保证。例如，一个标签页中的网站可读取用户在另一个标签页输入的密码，或结账页面广告读取信用卡号。
对云提供商和互联网公司同样破坏性：许多网站代码依赖编程语言的隔离保证，Spectre使这些保证失效。应用托管提供商需重新评估安全架构、重建核心代码（伴随性能损失），或两者兼施。
V1无通用修复方案，受影响软件需重新编译以避免易受攻击代码模式。浏览器厂商已移除高分辨率计时器（用于确定缓存状态）并积极避免易攻击代码模式。
我该怎么做？
更新浏览器、操作系统和BIOS至最新版本。所有浏览器厂商已发布Spectre漏洞缓解措施。主要云提供商已部署缓解措施，用户无需担心。
Spectre（变体2）
幽灵漏洞变体2允许程序读取无权访问的内存，无论内存属于同一程序、其他程序还是核心操作系统。与V1类似，V2也滥用分支预测、预测执行和缓存计时侧信道，但V2欺骗间接分支预测器。间接分支预测器无视权限变更（包括用户到内核、程序到程序、虚拟机到管理程序），因此V2攻击可跨现代处理器提供的几乎所有权限级别。
技术细节
Spectre V2攻击是三种已发布攻击中最复杂的。以下简化描述基于Google Project Zero博客的示例，攻击从客户虚拟机读取特权管理程序内存。
- 间接分支预测器通过分支历史缓冲区（BHB）记录最近执行的分支历史，以预测间接分支目标（图3）。通过测量分支操作时间，可“读取”BHB并确定先前执行指令的位置（即使在不同权限级别或程序中执行）。
- 分支预测器在处理器上所有程序间共享：一个程序中执行的分支改变间接分支预测器在另一个程序中的猜测。通过执行精心选择的分支序列，可“写入”BHB，强制预测器为未来间接分支猜测攻击者选择的位置（即使该分支在不同权限级别执行）。
攻击步骤（以云计算实例读取云控制平面内存为例）：
攻击准备
- 分配用于缓存计时侧信道的内存块
reader。 - 利用Linux内核的eBPF解释器创建所需代码模式：找到管理程序中的eBPF解释器位置（
eBPF_interpreter）、提供代码（ebpf_code）、找到间接分支位置（indirect_branch）。 - 通过BHB泄漏管理程序代码位置：请求管理程序执行正常操作，执行间接分支并存储位置到BHB，再“读取”BHB识别这些位置。
- 通过数学计算和多次尝试，找到管理程序中
reader、ebpf_code、indirect_branch和eBPF解释器的位置（图4）。
攻击执行
- 确保
reader未被缓存。 - 执行一系列间接分支，写入BHB新条目，欺骗间接分支预测器猜测
indirect_branch指向eBPF解释器（图5）。 - 设置处理器状态，使eBPF解释器执行
ebpf_code，读取管理程序内存字节并用该字节访问reader。 - 请求管理程序执行无害操作触发
indirect_branch，引发以下事件链：- 处理器猜测
indirect_branch指向eBPF解释器。 - 处理器开始预测执行eBPF解释器（同时开始倒计时直到发现错误分支目标）。
- eBPF解释器执行
ebpf_code，读取管理程序内存字节并访问reader的一部分，将其缓存。 - 处理器发现执行错误分支，撤销所有预测执行指令，但
reader的一部分已被缓存（图6）。
- 处理器猜测
- 通过计时访问
reader的每个部分，识别读取更快的部分，其索引即为从管理程序内存读取的字节值。 - 重复过程读取更多字节（可跳过攻击准备步骤）。
图6展示了Secrets在Spectre V2攻击中如何泄漏：eBPF解释器预测执行攻击者指定的eBPF代码，读取秘密值并用于访问reader，预测执行效果通过缓存计时侧信道观察。
影响是什么？
这对所有人都是坏消息：云提供商、互联网公司或普通网民。影响结合了Spectre V1和Meltdown的最坏部分。虽无针对浏览器的概念验证，但可能性不能排除。
对云提供商更糟：有概念验证利用打破云计算系统租户隔离的最强机制。不仅Intel，多种CPU架构的处理器都易受V2影响。
有多种缓解措施，但都有性能成本。处理器厂商通过更新微码减轻影响，软件可重新编译避免使用间接分支指令。修复性能损失尚无可靠数据，但肯定非零，且需额外支付修复Meltdown的代价。
我该怎么做？
更新操作系统和固件（BIOS或UEFI）至最新版本。最新系统和BIOS更新通过处理器微码更新、控制间接分支预测器行为的变通方案或重新编译避免间接分支，来缓解最严重的V2实例。
所有主要云提供商已部署缓解措施，用户无需担心。
这一切是如何发生的？
为何过去25年未被发现？原因有二：我们对计算的基本假设已改变，且许多安全暗示直到现在才被整合成工作概念验证。
预测执行在90年代消费处理器首次出现时，计算机使用方式不同：多数机器是单用户，当时最流行操作系统（Windows 9x和Mac OS Classic）缺乏内存保护。无需Spectre或Meltdown即可读取（甚至写入）其他应用内存。在那环境中，性能提升真实，安全影响不重要。
如今，多租户云计算（无论虚拟机或容器）支撑大部分网络。浏览器经常下载运行不可信代码（如JavaScript），并与其他不可信代码（如其他标签页）沙盒隔离。在这环境中，从一隔离内存 compartment 泄漏信息到另一 compartment（如浏览器标签间）是大问题。
多次暗示预测执行可能导致特权信息泄漏。Google Project Zero博客引用多个来源（包括我们Sophia D’Antoine的工作）暗示问题。多名独立研究者识别并报告Spectre和Meltdown漏洞，其他人非常接近。但认为可能有问题与写出概念验证证明问题真实存在差异巨大。报告此问题的研究者工作出色，本博客文章希望展示其难度。
结论
希望您从技术层面更好理解Meltdown和Spectre工作原理、影响和可用缓解措施。本文旨在让无计算机架构背景者易懂，真诚希望我们成功。对更技术性读者，Meltdown和Spectre论文及Project Zero博客文章是更好细节来源。
展望未来，计算平台的微架构攻击将是计算机安全激动人心领域。因许多部署平台易受Meltdown和Spectre影响，微架构攻击未来多年仍将相关且危险。
如果您喜欢本文，请分享： Twitter LinkedIn GitHub Mastodon Hacker News