文章总结： 安全研究员成功在CloudflareWorkers生产环境实施远程Spectre攻击，以12bits/秒速度窃取JWT，准确率99.16%。攻击者利用WebSocket延迟绕过定时器限制、通过DurableObjects延长生命周期绕过动态进程隔离、用I/O噪音掩盖分支预测错误信号。Cloudflare采用V8沙箱、MPK内存保护键及旋转内存布局进行防御。启示：serverless环境需硬件级隔离保障安全。 综合评分： 95 文章分类： 漏洞分析,云安全,web安全,红队,安全工具

从120 bits/小时到 12 bits/秒：硬核解析Cloudflare Serverless侧信道攻击

原创

Kit Chung Kit Chung

安全圈动向

2026年8月21日 08:21 广东

在小说阅读器读本章

去阅读

大家好，今天咱们来拆解一个最近安全圈和Serverless圈炸锅的重磅研究。

提到 Spectre攻击，大家可能还心有余悸。这个利用CPU分支预测机制搞侧信道数据窃取的“上古神兽”，最近又出来搞事情了，而且这次的受害者是 Serverless 领域的标杆——Cloudflare Workers。

安全研究员最近披露，他们成功在 Cloudflare Workers 的生产环境中实施了远程 Spectre 攻击，直接从“同居”的另一个 Worker 内存中把 JWT（JSON Web Token）给偷了出来！最离谱的是，泄露速度达到了 12 bits/秒，准确率高达 99.16%。相比2021年演示的那波攻击，速度直接狂飙了360倍。

今天，我就带大家深挖一下，这帮研究员到底用了什么“骚操作”绕过了 Cloudflare 的层层防御？Cloudflare 又是如何用底层黑科技进行反击的？

1. 为什么能被偷？V8 隔离的“妥协”

首先咱们得明白，为什么攻击者能碰到受害者的数据？这就不得不提 Cloudflare Workers 的底层架构设计。

传统容器（比如 Docker）用的是系统级别的进程隔离，安全是安全，但“冷启动”太慢了。为了追求极致的启动速度和高并发，Cloudflare Workers 没有选择传统的严格进程隔离，而是让多个租户的代码运行在同一个操作系统的进程中，仅仅依靠 V8 引擎的 Isolate（隔离区）来进行语言级别的隔离。

简单来说，以前大家是各住各的独栋别墅（进程隔离），现在是为了省钱省事，大家合租了一个大平层（同一个进程），每人分了个带锁的卧室（V8 Isolate）。

这种架构下，只要攻击者的 Worker 和受害者的 Worker 被调度到了同一个进程里的不同 V8 Isolate 中，Spectre 这种基于共享硬件微架构（比如CPU缓存）的侧信道攻击，就有了跨租户“穿墙”的理论基础。

2. 步步为营：攻击者的“神仙级”绕过路径

Cloudflare 当然不是吃素的，他们早就防着这一手了。他们不仅禁用了共享内存和多线程，还部署了名为 DyPrIs（动态进程隔离） 的防御机制。但这次的研究员，硬是打出了一套极其漂亮的组合拳。

🔥 突破口一：没有高精度定时器？用 WebSockets “徒手掐秒表”！ Spectre 攻击的本质是测量读取缓存的时间差（命中缓存快，未命中慢）。Cloudflare 为了防侧信道，故意冻结或者粗化了 CPU 执行期间的计时器。 没表怎么计时？研究员发现，WebSockets 通信网络延迟可以作为一个完美的远程时钟源！ 通过精心构造的网络往返时间（RTT），他们成功还原了精确的计时能力，拿到了第一把钥匙。

🔥 突破口二：绕过 DyPrIs 隔离？用 Durable Objects “赖着不走”！ Cloudflare 的 DyPrIs 机制会在一个脚本“执行结束”后，评估它是不是可疑分子，如果是，就把它扔进单独的进程里。 研究员的破解思路极其刁钻：既然你是执行结束后才隔离我，那我就永远不结束！ 他们利用 Cloudflare 的 Durable Objects (持久化对象) 特性，硬生生把单个 Worker 的生命周期拖长到了 5 到 20 个小时以上。在被隔离之前，数据早就偷完了。

🔥 突破口三：信号掩护，用 I/O 噪音“暗度陈仓” 这是整个攻击中最硬核的一环。DyPrIs 检测 Spectre 的核心依据是监控“分支预测错误 (Branch-misprediction)” 的信号频率。 为了把这个特征信号压到检测线以下，攻击者大量制造 WebSocket 的 I/O 活动。这种高强度的 I/O 操作直接引发了 iTLB（指令翻译后备缓冲器） 的剧烈活动，这就像是在撬锁的时候，故意在旁边放个高音喇叭播放电钻声。I/O 噪音极大地“稀释”了分支预测错误的归一化信号，让 DyPrIs 彻底变成了瞎子。研究员在论文中直言：“这不是代码实现的Bug，而是这种检测方法本身的根本性缺陷。”

(注：为了达到最佳效果，研究员专门挑了月黑风高的晚上，在 AMD EPYC Zen 2 / Zen 3 服务器 CPU 负载降到 10%~25% 时进行攻击，以降低系统噪音。)

3. 绝地反击：Cloudflare 的底层硬核防御

事发之后，Cloudflare 团队表示没有在过去三年发现生产环境被真实利用的痕迹，并迅速打出了一套极具技术含量的补丁包。咱们来看看大厂是怎么做安全加固的：

• V8 Sandbox (V8 沙箱)

  直接从内存访问层面设限，限制了恶意脚本对 64 位指针的瞬态访问，掐断了幽灵攻击乱指内存地址的念想。

• MPK (内存保护键) 进程内隔离 (核心亮点)

  Cloudflare 动用了硬件级的防御手段——MPK（Memory Protection Keys）。他们把每个 Worker 的堆内存放在了由硬件强制执行的保护键后面。 但这里有个巨大的技术难点：现代 x64 架构的 CPU，最多只提供大约 12 个可用的 MPK 保护键。如果同一进程里有几十上百个 Worker，必然会有多个 Worker 拿到相同的钥匙，这就会导致大约 92% 的跨租户非法访问无法被拦截。 Cloudflare 的解法：他们将 MPK 与 V8 Sandbox 深度绑定，并首创了一套“旋转内存布局 (Rotating Memory Layout)”。通过巧妙地编排内存位置，确保在物理内存上相邻的 Sandbox 绝对不会共享同一把“钥匙”。这波操作，直接用软件设计弥补了硬件资源的短板，可谓绝杀。

4. 给我们的启示

说实话，看完这篇研究，我最大的感触是：在 Serverless 和多租户云环境中，“性能”与“安全”永远在走钢丝。

依靠语言级隔离（V8 Isolate）带来的毫秒级冷启动确实香，但面对越来越底层的微架构攻击，应用层的防御（如早期的 DyPrIs）显得非常脆弱。这次攻防战再次证明，真正有效的安全隔离，最终还是要下沉到硬件层（如 MPK 和底层沙箱机制）。

对于我们普通的开发者来说，虽然不需要手写防御 Spectre 的底层代码，但理解这些底层逻辑，对我们在技术选型、架构设计以及处理敏感数据（如文中的 JWT）时，绝对有着巨大的参考价值。

兄弟们，如果你对这次的攻击细节和 V8 底层机制还有什么疑问，欢迎在评论区留言，咱们一起探讨！

Cloudflare #Serverless架构 #网络安全 #底层原理 #V8引擎

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung Kit Chung《从120 bits/小时到 12 bits/秒：硬核解析Cloudflare Serverless侧信道攻击》