探测+检测+缓解(PDM):让云租户自主防御微架构攻击
文章目录1. 引言1.1 背景微架构攻击在云环境中尤其令人担忧1.2 论文的防御思路1.3 四个核心挑战1.4 解决方案——PDM框架概览1.5 主要贡献1.6 实验结果2. 预备知识2.1 微架构攻击缓存侧信道攻击瞬态执行攻击2.2 威胁模型PDM 的安全覆盖范围3. 研究方法3.1 探测方案1AccessReload用于检测驱逐型攻击方案 2FlushReload检测瞬态执行攻击方案 3方案 1 方案 2同时检测两类攻击3.2 检测注入检测引擎噪声处理3.3 缓解缓存侧信道攻击的缓解混淆瞬态执行攻击的缓解内存加密4. 评估5. 相关工作5.1 基于 HPC 的检测主流但租户用不了5.2 其他基于探测的检测思路接近但场景不同5.3 缓解方案前人很多但租户用不了或开销大6. 限制和讨论6.1 其他微架构攻击覆盖范围的局限性6.2 慢速逃避攻击6.3 Spectre 的逃避6.4 内存加密的掩码保护6.5 秘密标注7. 总结论文《PROBEDETECTMITIGATE (PDM): Enabling Cloud Tenants to Self-Defend against Microarchitectural Attacks》1. 引言1.1 背景微架构攻击在云环境中尤其令人担忧微架构攻击利用共享 CPU 缓存和不安全的硬件优化来窃取信息在多租户公有云环境中尤其危险因为不同租户可能共享同一台物理主机。你和几十个不认识的人共用同一台物理机的 CPU、缓存、内存只要有人在这台服务器上运行恶意代码就能偷走你的隐私数据虽然云安全是 “共享责任模型”租户负责自己的数据安全厂商负责基础设施安全但在微架构攻击面前云租户往往是束手无策的。因为现有检测方案大多需要访问硬件性能计数器HPC或宿主机进程信息而这些租户根本拿不到。如图一左侧所示另一方面若采用现有的代码/二进制加固技术来防范微架构攻击如恒时代码、插入内存屏障或内存加密如果不加选择地应用可能会带来显著的性能开销而页表修改类解决方案如将页面标记为不可缓存或使用仅执行内存通常需要访问主机或管理程序这对租户来说同样可能无法实现。再另一方面服务商可能因为性能开销大、补丁滞后等原因迟迟不部署防御。对比之前学的 AegisAegis 看起来很美好但它有一个致命的前提防御者能在虚拟机内部读取 HPC 的值。但在真实的 AWS 亚马逊云科技共享实例上这个前提根本不成立原文还指出像 PRIMEPROBE 和 Spectre 这些攻击明明有补丁但依然活跃。说明光靠服务商不够。因此有必要让云租户具备抵御微架构攻击的能力。这可以i提高租户对微架构攻击的认知进一步吸引公众关注这一活跃威胁ii迫使供应商和服务商更及时地开发并部署供应商补丁iii提供额外的防护层与现有的服务商及检测和缓解方案协同工作。1.2 论文的防御思路核心思路分为两点第一租户可以用和攻击者一样的探测技术来检测攻击。比如 FLUSHRELOAD 攻击能用来偷数据反过来也能用来检测有没有人在偷你的数据。第二我们可以只在检测到攻击的时候才触发防御这样就能把性能开销降到最低。这样一来你不需要任何特殊权限只需要能执行普通的用户态指令就能检测到所有主流的微架构攻击。1.3 四个核心挑战要实现这个想法我们需要解决四个关键挑战第一很多微架构攻击不涉及缓存驱逐比如 Spectre第二你不能修改用户的程序代码也不能全局插桩修改源码不现实二进制插桩开销大将探测过程注入受害者的进程可能需要这些操作。第三要能处理云环境里各种各样的噪声第四要平衡检测精度、延迟和开销。1.4 解决方案——PDM框架概览为应对这些挑战我们推出了PDM这是一种供云租户在无需云服务商协助的情况下抵御微架构攻击的解决方案。ProbeDetectMitigate框架一系列探测方案使云租户能够独立检测各种微架构攻击。PDM 作为线程注入到受害者进程里不需要修改源码选择性触发防御平时不开检测到攻击才开1.5 主要贡献真正的租户级防御不依赖服务商提供任何特殊资源HPC、宿主机权限租户自己就能部署。解决了上述四个挑战i覆盖各类微架构攻击ii无需修改源代码或进行二进制插桩iii处理来自多种来源的噪声iv在性能开销与准确性之间取得平衡。在真实云环境中验证了方案的有效性1.6 实验结果2. 预备知识2.1 微架构攻击缓存侧信道攻击攻击者通过测量内存访问延迟判断目标缓存行是否被受害者加载进缓存从而推断受害者的内存访问模式进而恢复密钥等敏感信息。典型攻击包括FLUSHRELOAD、FLUSHFLUSH、EVICTRELOAD、PRIMEPROBE 及其变种、RELOADREFRESH 等禁用内存共享可以防 FLUSHRELOAD等攻击因为它们需要共享内存但对 PRIMEPROBE 无效不需要共享内存随机化缓存或缓存分区可以防御但需要改硬件或牺牲性能。关键观察PDM 探测的基础所有缓存侧信道攻击都会把受害者的数据从缓存里踢出去。这会导致受害者下一次访问这个地址时出现异常的缓存缺失瞬态执行攻击这类攻击利用现代 CPU 的乱序执行和推测执行优化如Spectre 攻击。当 CPU 发生预测错误时会回滚所有架构状态但微架构状态比如缓存不会被回滚。攻击者可以利用这个残留的微架构状态窃取数据。例如Spectre变种攻击中攻击者可以利用程序中看似安全的代码片段把程序的正常执行流拐向一段能读取秘密数据的特殊指令序列即“小工具”。这是通过强制引发条件分支预测错误PHT、间接分支预测错误BTB、返回地址预测错误RSB 或内存读取预测错误STL 来实现的。虽然 CPU 事后反悔了执行效果会被回滚但秘密已经被带进了缓存。最后攻击者用 FLUSHRELOAD 等测时手段把缓存里的秘密“偷渡”出来。自从 Spectre 和 Meltdown 出现后类似的攻击便层出不穷。关键观察PDM 探测的另一个基础所有瞬态执行攻击都会把受害者的数据偷偷拉进缓存里。这会导致受害者下一次访问这个地址时出现异常的缓存命中cache hit而厂商的补丁“永远修不完”且“性能代价巨大”导致云服务商往往不愿意全量部署。因此作为云租户你不能指望靠厂商的补丁来保命必须自己想办法比如用PDM在应用层建立最后一道防线2.2 威胁模型作者采用文献中标准的微架构攻击威胁模型攻击者是与受害者同驻在同一物理主机上的普通云租户。攻击者只能在自己的云实例中执行非特权代码没有特权指令或提升权限。云提供商已禁用租户对主机或硬件级信息包括 HPC的直接访问。租户信任服务商但也意识到服务商可能无法及时跟进所有新型攻击或不愿部署所有防御因性能开销。只考虑真实云环境有噪声数据泄露速率相对较低如 Spectre-PHT 只有 41B/s跨 VM 的攻击需要数秒或数分钟通俗解释攻击者是谁就是云上另一个坏租户和你开在同一台物理机上的虚拟机或容器。攻击者有什么能力能执行普通代码能读自己的内存能测量时间。攻击者没有的能力不能读 HPC服务商禁了不能改内核不能提权。环境特点云环境不是寂静的实验室有很多正常负载造成的“噪音”缓存争用、调度延迟。但好消息是数据泄露速率也不高比如 Spectre 一秒只能偷 41 字节所以防御方有时间反应。PDM 的安全覆盖范围PDM 能检测和防御那些影响受害者缓存占用状态的攻击即攻击会改变受害者数据在缓存中的分布。其次PDM 能够检测但无法缓解仅部分覆盖那些将 Spectre 用于直接数据泄露和内存拒绝服务之外目的的攻击因为这些攻击针对的是完整性或可用性而非机密性。最后那些不改变受害者缓存占用状态的攻击不在覆盖范围内未被覆盖。为了更全面地了解这类攻击的覆盖范围作者分析了过去十年在主流安全顶会上发表的169篇微架构攻击相关论文。研究发现28%的论文针对幽灵漏洞37%针对基于缓存的侧信道攻击。这表明尽管PDM仅能访问租户级别的资源但其仍覆盖了大部分常见攻击类型。3. 研究方法概述PDM 由三个主要组件组成探测、检测和缓解。首先探测组件监控受害者的内存空间捕获异常的缓存命中或缺失作为检测特征。其次检测组件包括三个子模块注入模块将 PDM 作为线程注入受害者进程检测引擎使用两级分类器处理特征噪声处理模块过滤来自受害者和同驻租户的噪声。最后缓解组件在检测到攻击时通过缓存混淆或内存加密阻止数据泄露。一句话概括用攻击者的技术探测自己的内存→用机器学习判断有没有人在攻击→只有真的被攻击了才启动防御和之前学的 Aegis 最本质的区别Aegis持续注入噪声不管有没有攻击都有开销PDM检测到攻击才启动防御平时几乎零开销3.1 探测本节设计了一系列探测方案用于监控目标的内存空间并收集数据以进行检测通过主动访问内存感知攻击者留下的“痕迹”。方案1AccessReload用于检测驱逐型攻击适用对象FLUSHRELOAD、PRIMEPROBE 等会把受害者数据踢出缓存的攻击。检测微架构攻击的一个直接方法是关注攻击者驱逐操作导致的异常缓存缺失。当攻击者驱逐、刷新或填充受害者的数据时我们可以通过探测相同的内存地址来检测攻击因为访问会由于缓存缺失而变慢。Access我先访问一下自己的秘密数据把它加载到缓存里Wait等一小段时间比如 0.3ms这段时间就是 “攻击窗口”Reload我再访问一次这个地址测一下时间判断如果时间很长超过缓存命中阈值说明有人在 Wait 阶段把我的数据踢出了缓存→可能有攻击为什么这个方案有效所有缓存侧信道攻击的第一步都是清空受害者的缓存。只要在攻击窗口内发生了清空操作受害者第二次访问就会变慢。这个方案就是专门抓这个 “清空” 动作的。方案 2FlushReload检测瞬态执行攻击适用对象Spectre 等推测执行攻击攻击者不会踢出你的数据反而会把你的数据带进缓存方案 1 只能监控缓存缺失无法检测依赖推测内存访问而不是驱逐的瞬态执行攻击为了解决这个问题我们借用了 FLUSHRELOAD 攻击的探测技术先刷新内存然后访问它任何在等待窗口内发生的投机内存访问都会被检测为异常缓存命中。具体做法FLUSHRELOAD 攻击能用来偷数据反过来也能用来检测有没有人在偷你的数据Flush先用 clflush 把目标地址从缓存中清空Wait等待Reload再读该地址测量时间如果 Reload 很快cache hit→ 说明在等待期间有人攻击者通过推测执行把你的数据加载进了缓存 → 可能遭受 Spectre 攻击方案 3方案 1 方案 2同时检测两类攻击由于方案 1 和方案 2 都只能检测一部分攻击方案 3 自然地将这两个基本方案结合起来。具体来说它对每个地址交替执行方案 1 和方案 2。这样既能抓驱逐攻击也能抓瞬态执行攻击。方案 3多路复用方案 3扩大探测范围在等待间隔内不闲着而是对多个地址依次执行第一次操作Access 或 Flush然后再依次执行 Reload。这样一次等待窗口可以覆盖最多 512 KiB 的内存范围提高探测效率。3.2 检测本节详细介绍 PDM 如何将自身注入受害者进程以检测攻击同时处理噪声。把探测到的原始数据快/慢、命中/未命中转换成特征用机器学习判断是否真的被攻击同时处理好噪声。注入PDM 的注入分两步地址提取和代码注入。地址提取离线执行用于定位秘密依赖的内存访问指令和秘密本身。代码注入将 PDM 作为线程加载到受害者进程中不需要修改源码或二进制。第一步地址提取离线只做一次先找到你的程序里哪些内存地址存了敏感数据方法用现有的自动化缓存侧信道漏洞扫描工具比如 Microwalk、CacheQL扫描二进制文件结果得到一个敏感地址列表这就是 PDM 的探测范围优点离线执行不影响运行时性能支持没有源码的二进制文件第二步代码注入运行时执行将 PDM 编译成共享库原文明确说了不用动态二进制插桩DBI因为 DBI 开销太大。PDM 用了两种更轻量的方式启动时注入用LD_PRELOAD环境变量在程序启动时自动加载 PDM 共享库运行时注入用ptrace系统调用把 PDM 共享库注入到已经在运行的进程里注入后PDM 会作为一个独立的线程运行和受害者共享同一个地址空间能直接访问所有敏感内存。而且这个线程被绑定到和受害者同一个 CPU 核心上保证能准确探测到缓存状态变化。检测引擎PDM 检测引擎将 探测模块输出的数据 组织为多元时间序列并使用推理开关触发两级检测过程以平衡精度、开销和前置时间。核心设计多元时间序列特征探测模块输出的数据比如 AccessReload 的命中/未命中比例、FlushReload 的命中比例被组织成时间序列。这些特征经过移动平均、移动标准差、归一化后输入一个轻量级 Transformer 分类器推理开关虽然我们的分类器很轻量但持续执行 ML 推理仍然会引入不必要的开销。因此我们引入了推理开关只有当秘密被访问或驱逐时才触发 ML 推理。如果一直跑机器学习CPU 开销会很大。所以加了开关只有当探测数据出现异常时比如 AccessReload 出现了慢读或者 FlushReload 出现了快读才触发 ML 推理。否则开关关闭不做 ML。两阶段检测平衡速度和精度快速模型fast classifier调参目标是低漏报尽量不错过攻击。一旦它报警立即触发缓解。慢速模型slow classifier调参目标是低误报确认是不是真攻击。如果它确认是误报就撤销缓解如果确认是真攻击就保持缓解并通知租户/服务商迁移或进一步处理。这样既保证了低延迟快速模型很快响应又避免了长期误报慢速模型可以修正。流程快模型先报警→立即启动轻量级防御→慢模型在后台验证→如果是假阳性就关防御如果是真攻击就升级防御噪声处理租户级解决方案自然会受到各种背景噪声的影响包括来自受害者应用本身的噪声和来自同驻租户的噪声这会导致检测出现大量假阳性。受害者噪声自己的正常访问问题受害者自己正常访问敏感数据也会导致缓存命中 / 缺失会被误判为攻击解决用另一个线程监控受害者是否正在主动访问这些地址。如果是就调整探测窗口避免误判。同驻噪声其他租户的噪声问题其他租户的缓存密集型应用会把整个 L3 缓存占满导致受害者的缓存缺失率上升解决专门开一个线程监控整个 L3 缓存的整体负载。PDM 收集 L3 整体负载作为额外特征动态调整探测的等待间隔3.3 缓解PDM 通过仅在检测到攻击时触发缓解措施来实现高效的攻击缓解。它利用了几种用户空间缓解方法包括混淆用于缓存侧信道攻击、内存加密用于瞬态执行攻击和迁移用于确认的攻击。这是 PDM 开销极低的核心原因平时完全不做防御只有检测到攻击才启动。而且所有缓解措施都是非破坏性的即使是假阳性也不会影响应用的正常运行。缓存侧信道攻击的缓解混淆存侧信道攻击旨在推断受害者的内存访问模式一个众所周知的缓解方法是混淆这些模式以增加攻击者观察到的噪声。PDM 采用两级混淆方法。第一级PDM 自己的探测操作Access/Flush/Reload本身就会扰乱缓存状态增加攻击者的噪声。第二级对受攻击的内存页进行主动预取prefetch不断把数据拉回缓存让攻击者看到一片混乱无法分辨真实访问模式。这个防御不仅没有开销反而会提高应用的性能—— 因为预取会减少应用自己的缓存缺失。瞬态执行攻击的缓解内存加密原理把敏感数据在内存中加密存储用 XOR 掩码只有在合法访问时才解密。实现方法概述1. 把包含秘密的内存页标记为 PROT_NONE禁止访问2.当受害者正常访问时会触发 SIGSEGV 信号信号处理器构建一个“跳板”trampoline计算真实访问地址读取加密数据 → 解密 → 放入寄存器执行原指令跳回原程序3.当攻击者推测执行时CPU 不会在猜测阶段触发信号因此拿不到解密后的明文只能拿到密文 → 攻击失败。确认攻击后的进一步行动一旦慢模型确认了检测到的攻击租户可以采取更激进的缓解措施比如迁移工作负载并通知云提供商。如果真的被持续攻击PDM 会报警用户可以用用户态 checkpoint/restore 工具比如 CRIU把容器迁移到其他物理主机上彻底摆脱攻击者。4. 评估核心结论PDM 在完全不需要任何云厂商支持、没有 HPC 访问权限的情况下实现了极高的检测精度本地 TPR≥99.72%FPR≤0.13%AWS Fargate TPR≥98.63%FPR≤0.83%极低的性能开销SPEC CPU 2017 平均 2.47%无攻击时几乎为 0完美的缓解效果完全阻断所有主流缓存攻击和 Spectre 变种极强的鲁棒性能有效处理云环境中的各种噪声对抗规避攻击的能力远优于现有方案5. 相关工作前人做了什么PDM 和他们有什么不同论文把所有现有微架构攻击防御方案分成了两大类逐一指出它们的致命缺陷从而凸显 PDM 的独特性。5.1 基于 HPC 的检测主流但租户用不了CacheShield受害者自己监控 HPC 来检测攻击。效果不错但需要 HPC 访问权限。Cho et al.监控整个系统的 HPC 来找到攻击者进程。同样需要 HPC。其他类似工作基本都依赖 HPC 或宿主机的全局视图。PDM 的不同完全不依赖 HPC只用租户自己能访问的资源自己的内存、自己的 CPU 时间。5.2 其他基于探测的检测思路接近但场景不同有工作针对 SGX enclave 做类似的探测但他们需要 HPC 或页表访问权限云租户拿不到。WaitGuard监控特定缓存行来检测 flush 攻击但依赖特定 CPU 型号。PDM 的不同不依赖任何硬件特性或特权纯用户态且覆盖更广包括 Spectre。5.3 缓解方案前人很多但租户用不了或开销大常量时间代码、内存 fences、标记页为不可缓存要么需要改代码要么需要内核模块要么性能开销大。Cipherfix对敏感数据持续加密但始终有开销哪怕没攻击。PDM 的不同只在检测到攻击时才触发缓解混淆/加密无攻击时几乎零开销。而且所有缓解都在用户态完成不依赖宿主机一句话总结前人工作要么需要 HPC/宿主机特权租户拿不到要么一直开着重防御开销大。PDM 是第一个纯租户级、按需触发、能同时对付缓存攻击和 Spectre 的自防御方案。6. 限制和讨论作者指出 PDM 目前还不能覆盖所有情况以及未来可以改进的方向。6.1 其他微架构攻击覆盖范围的局限性PDM 专注于那些通过主动内存探测改变受害者缓存占用状态的攻击。对于不改变缓存状态的攻击PDM 目前无法覆盖。如果要覆盖可以扩展探测思路例如针对端口竞争可以部署一个并发线程去探测 CPU 端口的延迟变化同样可以用“探测”的思路来检测。这展示了用攻击的侧信道技术反过来做防御的思想可以推广。6.2 慢速逃避攻击攻击者可以故意放慢攻击速度来躲避检测。放慢攻击速度试图让自己的行为淹没在正常的系统噪声中。虽然理论上存在这种攻击但在真实云环境中几乎没有实用价值耗时太长但依然可以通过增加一个专门的 “慢速模式” 探测线程来解决。6.3 Spectre 的逃避PDM 检测 Spectre 的依据是推测执行导致的意外缓存命中。要完全逃避检测攻击者必须消除推测执行对缓存的影响但这极具挑战性。6.4 内存加密的掩码保护一个合理的担忧内存加密的XOR 掩码本身也可能成为攻击目标。PDM 的设计每次写操作都会用 AES 伪随机数生成器PRNG刷新掩码所以掩码的有效窗口很短。此外可以把掩码也加入 PDM 的探测范围监控是否有异常访问。也可以让掩码依赖于一个很长的秘密使得攻击者必须泄露整个秘密才能推导出掩码。6.5 秘密标注PDM 需要提前知道哪些内存地址包含秘密以确定探测范围。这通常需要开发者手动标注或使用半自动化工具。7. 总结PDM 使云租户无需依赖服务商资源即可自主检测和缓解缓存侧信道攻击与瞬态执行攻击i通过探测监控受害者的内存空间ii以线程形式注入自身以检测攻击并处理干扰iii在检测到攻击后缓解数据泄露问题。并通过实验证明了其有效性、高效性和鲁棒性从而提升租户安全意识、推动服务商改进并作为现有防御的补充层。

相关新闻