企业官网建设流程全解析

Firefox 152.0.5备份恢复RCE：浏览器投毒到NSS DLL加载全链条指南

【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium

🔥 想理解Firefox RCE（远程代码执行）是怎么发生的？开源漏洞研究归档项目Exploitarium中有一组现成的实证材料：一次普通的浏览器点击，就能让正版签名的 Firefox 152.0.5 恢复攻击者伪造的"备份"，并加载攻击者指定的NSS DLL，最终以弹出计算器完成 RCE 证明。本文带你用通俗的方式走读这条完整的浏览器投毒链。

📦 Exploitarium 是什么？

Exploitarium 是一个公开的漏洞 PoC（概念验证）研究归档库，收录了数十个尚未被官方认领的安全研究 PoC，涵盖浏览器、开发工具、网络库等多个目标。其中与 Firefox 直接相关的就有 3 个独立研究条目：

⚠️ 项目方明确声明：所有材料仅限授权复现、浏览器加固和回归测试用途，严禁恶意使用。已分配的 CVE 编号清单见 cves.md。

🗺️ 攻击链全景：一次导航，四步到 RCE

这条链的巧妙之处在于：全程只有用户的一次导航操作，后续所有步骤都是自动完成的。整条链路横跨浏览器 4 道原本相互独立的防线：

① 投递阶段：让浏览器"自己下载"武器

PoC 的入口是一个本地 Python 服务器（server.py）。它启动后会做三件事：

1. 读取 Windows 注册表中的Downloads 已知文件夹路径（get_downloads_directory）；
2. 预先构造好一份伪造的 Firefox 备份档案FirefoxBackup_RCE.html；
3. 打印访问地址http://127.0.0.1:8896/。

当你在 Firefox 中打开该地址后，exploit.html 会连续派发两个下载：

• firefox_calc_payload.dll—— 最终的计算器证明载荷；
• FirefoxBackup_RCE.html—— 伪装成备份文件的"恢复档案"。

这一步完全依赖用户"自动保存到下载目录"的默认行为，没有任何弹窗干扰。

② 内存破坏阶段：Wasm JIT 漏洞拿下内容进程

Firefox 的多进程架构本是安全护城河——网页代码跑在低权限的内容进程里，碰不到浏览器核心对象。但这条链的第一步突破口正是一个Wasm / Baseline-JIT 内存安全漏洞：

• child_id_probe.wasm 被注入内容进程执行，利用 JIT 编译缺陷破坏执行流；
• 利用泄漏出的 JIT 返回地址，推导出原生执行入口的位置（偏移量写死在 exploit.html 中，仅对 152.0.5 的 Windows x64 二进制有效）；
• 最终在原生层遍历子窗口上下文结构，把目标BrowsingContext标识符回传给 JavaScript。

💡 对新手而言，这一步的本质是：网页通过 Wasm 拿到内容进程内的任意代码执行权——后续一切都以此为跳板。

③ 权限跃迁阶段：BrowserBridge 直入特权页面

拿到内容进程控制权后，攻击者仍无法直接操作浏览器主流程，因为特权 UI 运行在另一个受保护的页面类型里。于是第二步原生载荷登场：

• native_browserbridge.wasm 解析出上一步得到的BrowsingContext对应的BrowserBridgeChild；
• 构造一个携带系统级 principal（最高权限）的加载状态，把子页面直接导航到about:welcome（导航派发代码）；
• 再通过第二次 BrowserBridge 加载，在该特权页面内执行一段javascript:URI 脚本。

问题的根源在于about:welcome使用的privilegedabout共享远程类型上，BackupUI 这个"子 Actor"会接受来自页面的自定义事件并转发给父进程，而父进程侧只校验了"事件来自哪个进程"，却未绑定"请求来自哪个可信文档"。

④ 致命一击：备份恢复 + NSS DLL 加载

进入特权页面后，脚本模拟官方恢复界面的操作，依次派发两个事件：

1. BackupUI:GetBackupFileInfo—— 让 Firefox 验证那份伪造备份；
2. BackupUI:RestoreFromBackupFile—— 执行"恢复到新配置集"并自动启动。

伪造备份的构造逻辑在 build_backup.py 中，它的"内鬼"藏在credentials_and_security（凭据与安全）资源里——一个名为pkcs11.txt的 NSS 模块数据库文件（pkcs11_text）：

library=C:\Users\<用户>\Downloads\firefox_calc_payload.dll name=Firefox Calculator Module

当恢复后的 Firefox 父进程启动时，NSS 初始化会解析这份文本数据库，并调用系统加载器加载library=指向的 DLL。而那个 DLL（源码见 calc_payload.c）只在DllMain的进程挂载入口里做了一件事：

WinExec("calc.exe", SW_SHOWNORMAL);

计算器弹出 = RCE 达成✅。注意该 DLL 的 PE 导出表是空的，它甚至不需要 NSS 成功解析 PKCS#11 接口——入口点执行本身就够了。

🧪 如何在本地复现？

完整步骤见官方说明 README.md，摘要如下：

只需在 PoC 目录运行python -B server.py，用 Firefox 打开打印出的http://127.0.0.1:8896/，其余全自动：两个文件落盘 → 备份验证 → 新进程恢复 → 计算器启动。所有中间事件都会写入proof.jsonl证据日志，2026-07-11 的仓库回放记录显示从导航到计算器弹出仅约19 秒。

📌 再次强调：复现仅限授权测试环境，请勿用于任何未授权系统。

🛡️ 研究者的修复建议

PoC 作者在 Fix Direction 章节 给出了 6 条加固方向，值得浏览器开发者与学习者参考：

• 绑定可信来源：BackupUI 操作应校验文档 principal 与精确的批准 URI，而非仅凭进程归属；
• 要求可信激活令牌：选择档案与派发恢复操作都需由真实恢复界面创建的凭据；
• 加密策略一致性：恢复流程应与备份创建一样强制执行资源加密（本 PoC 的档案encConfig为null）；
• 拒绝外部模块路径：凭据/安全资源恢复只接受经过校验的文件，拒绝外部pkcs11.txt库路径；
• 加载前验证：NSS 在加载库之前先校验模块配置合法性。

📁 相关文件索引

写在最后：这条链的价值不在于"多凶险"，而在于它展示了浏览器攻防中最典型的组合拳思路——低危原语（JIT 内存破坏）+ 信任边界滥用（Actor 事件校验缺失）+ 功能滥用（备份恢复的 NSS 模块加载），三个单点问题各自看起来都"不太严重"，串起来却是完整的 RCE。这正是 Exploitarium 作者想传达的：理解这些链条，是进入安全研究领域的最短路径。

【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium