G.O.S.S.I.P 阅读推荐 2025-03-28 抵御微架构攻击的奥利奥

今天给大家介绍的论文是来自 NDSS 2025 的 Oreo: Protecting ASLR Against Microarchitectural Attacks，作者为 ASLR 这一保护方案本身又设计了一套新的软硬件协同保护方案，防止攻击者通过微架构侧信道绕过 ASLR 保护。

基于微架构的侧信道攻击并不只是好看而已，在现实世界的漏洞利用中，微架构攻击是一种很值得考虑的绕过地址随机化的手法。比如Project Zero在《Exploiting CVE-2022-42703 - Bringing back the stack attack》(https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html)这篇博客中介绍了借助 prefetch 侧信道，从用户态打败 KASLR 的方法。

或许你觉得 meltdown、spectre 这些臭名昭著的漏洞过了这么多年，肯定已经被防御得差不多了，但谁也不知道硬件设计厂商会为了压榨性能而整出什么新活，为一条架构上普普通通的 save/load 增加多少微架构层面的 side effect。我们并不知道未来还会有哪些新的侧信道。而且糟糕的是，几乎每一种新发现的侧信道攻击变种都可能成为绕过 ASLR 的新向量，换言之，ASLR 对侧信道攻击非常脆弱。

由于上述原因，ASLR 受到的威胁正如Project Zero博客中所言：“KASLR 在 x86 架构上已被本地攻击者全面攻破，过去几年一直如此，而且在不确定的未来仍将如此。”

对于侧信道本身的防御常常是针对某个特定信道而言的，比如一种常见的防御方法是去限制用户获取某个信息的精度。但这样的做法并不通用，需要工程上不断进行调整。作者从保护目标（即 ASLR）的角度出发，尝试为其设计一套通用的防御方法，面向过去、现在以及未来的侧信道攻击。

为了达到这个目的，我们首先要看看侧信道攻击是如何打败 ASLR 的、为什么 ASLR 面对侧信道如此不堪一击。作者把已有的攻击抽象、分类出三种使用微架构攻击绕过 ASLR 的路径。

第一类以 prefetch 为代表的攻击基于虚拟地址空间中已映射地址和未映射地址的不同，攻击者会在整个虚拟地址空间中暴力搜索（或者提前知道目标的大致范围），找到那些存在映射的地址。如果攻击者直接用访存指令来遍历虚拟地址，硬件上直接就 segmentation fault 了，根本没法搜。然而，包括 prefetch 在内的一些操作缓存的指令、Intel TSX 指令在访存失败时，硬件会直接忽略而不是发起异常。这样一来攻击者就可以持续进行搜索，下面就是一个简单的代码例子：

第二类攻击中，攻击者监控受害者使用指针取指或执行访存操作所造成的 side effect，我们直接来看下面这个 AnC 攻击。

第三类攻击的目标是作为数据的指针，攻击者利用 Spectre 类型的攻击直接去泄漏某个地址的指针内容。就和使用侧信道泄露密钥一样，这里只是把密钥换成了经过随机化之后的指针。（这个比较基础所以我们就不放图片了。）

论文提出的 Oreo 方案可以缓解前两类攻击。在 Oreo 的世界观下，一个虚拟内存空间中的内存段不再孤单，而是分化出了多个分身。从各种微架构的角度看来（Cache、TLB、BTB 等等），这些分身都和本体是一模一样的，只有从架构层面访问他们（实际地去 load/store），它们才体现出了区别，对于分身的访问会报一个异常。只要分身数量足够多，攻击者就很难猜中哪一个才是本体！

这种效果的背后，是在虚拟内存和物理内存之间的一层新的抽象——Masked Memory。我们首先在一个虚拟地址中选定一些位作为 protected bits 或 masked bits，比如对于虚拟地址 0xFFAB12340，我们可以选定（小端）第 20~27 个 bit 作为保护。这样，虚拟地址空间中所有形如 0xFF??12340 的地址都会在 Masked Memory 中对应到同一个地址。由于在进行这个映射时，选定的 protected bits 会被直接 mask 掉，所以中间这层抽象才叫做 Masked Memory~~，而不是因为作者是马斯克的粉丝~~。所有的微架构操作，比如页表、BTBs、TLBs 等，都只根据 mask 后的地址进行索引等操作，因此我们可以说，本体 0xFFAB12340 和分身 0xFF??12340 们在微架构的层面上没有任何区别。

我们此时回顾第一、二类的攻击者，他虽然可以通过微架构侧信道定位到所有的分身，但在 (2^8 -1) 个分身的保护下，攻击者依然很难找到实际的映射位置。

当然，本体和分身还是有区别的，对于一个虚拟地址的有效性检查被推迟到了指令的提交阶段，这样就可以确保只有在架构层面而非微架构层面才能区分有效和无效地址。关于 protected bits 的选择以及和现有系统的兼容性讨论，此中讲究也不小。比如，protected bits 选择得越多，攻击者猜中某一个分身地址的概率就越大，由于分身和本体在微架构视角下完全相等的，他就可以直接使用类 spectre 攻击从微架构层面泄露秘密数据。具体细节可以见原论文。

作者在 Linux 6.6 上实现了 Oreo 原型，并在 gem5 硬件模拟器上评估了设计。为了实现 Oreo，作者在以下硬件模块上做出了修改：

相信读者也可以发现，Oreo 涉及的计算其实非常简单，无非是一些位运算和比大小，也不涉及访问内存中的额外信息。通过 SPEC2017和 LEBench 基准测试，Oreo 展示了几乎可忽略不计的性能开销（平均0.11%）。

可惜的是，Oreo 对第三类攻击，即 spectre 类型攻击的防护能力完全不存在。作者表示，在实施全面的防御时，仍需依赖现有的 Spectre 缓解方案，将 Oreo 与它们同时部署。但总的来说，这种防御方式非常有趣，对性能影响也不大，看起来非常 fancy。

原文链接：ndss-symposium.org/wp-content/uploads/2025-264-paper.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2025-03-28 抵御微架构攻击的奥利奥