00:00:00
资料库 · 漏洞研究与利用链
第 ④ 卷，条目 61–80。来源为 Google Project Zero 与 Mozilla Security Blog。
这一卷的内容比前三卷底层得多——内核、基带、浏览器渲染引擎。如果你只做 Web 开发，这些漏洞你一个都碰不到。 但我认为这一卷值得读，理由只有一个：
它会永久改变你对"低危"的判断。 零点击利用链的每一环单独看都不算严重——一个信息泄露、一个越界读、一个绕过某个缓解机制。串起来就是"给你发一条消息就能完全控制你的手机"。看过几条完整链子之后，你在评审里看到"这个只是泄露了内存地址，影响有限"时的反应会不一样。
零点击利用链
61. A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens
来源：Google Project Zero，2026 年 5 月。
读它解决什么：一条针对最新旗舰手机的零点击利用链的完整分析。
要点：
- Pixel 10 的零点击（0-click）利用链
- 标题"一扇门关上，一扇窗打开"暗示某条路被修补后研究者找到了新路径
我的补充：零点击意味着受害者不需要做任何事——不点链接、不装应用、不接电话，收到一条消息就够了。这是威胁模型里最严重的一档，也是商业间谍软件的主要形态。标题那个隐喻值得注意：它说明修补单个漏洞往往不改变可利用性，只要那个攻击面（自动解析不可信输入的组件）还在，新的入口就会被找到。这对防御方的启示是要区分"修漏洞"和"消除攻击面"——前者是必要的应急，后者才是根治。手机上具体能做的：开启 Android 的高级保护模式或 iOS 的锁定模式，它们的做法正是关闭攻击面（禁用不必要的解析器和自动预览），而不是逐个修漏洞。
62. A 0-click exploit chain for the Pixel 9 Part 1: Decoding Dolby
来源：Google Project Zero，2026 年 1 月，三部曲第一篇。
读它解决什么：一条零点击链的起点：音频解码器中的漏洞。
要点：
- Pixel 9 零点击链的第一部分，涉及 Dolby 音频解码
- 三篇系列的开头，说明这条链有多个阶段
我的补充：起点是音频解码器这件事很说明问题。多媒体解析器是移动端最理想的攻击入口：格式极其复杂（几十年积累的容器和编码变体）、代码多为 C/C++、而且在用户看到内容之前就自动运行了（生成缩略图、预览、自动播放）。这解释了为什么"不点开那条消息"往往没用——解析已经发生了。对普通用户的实际建议：关掉聊天应用的媒体自动下载，这一个设置就消除了大部分这类入口。
63. A 0-click exploit chain for the Pixel 9 Part 2: Cracking the Sandbox with a Big Wave
来源：Google Project Zero，2026 年 1 月，三部曲第二篇。
读它解决什么：拿到解码器内的代码执行之后，如何逃出沙箱。
要点：
- 系列第二部分，主题是沙箱逃逸
- 说明第一阶段的代码执行被限制在沙箱内
我的补充：这一环证明沙箱是有效的——攻击者拿到解码器里的代码执行之后，还得再花一个完整的漏洞才能出来。这是纵深防御的实际价值：它不阻止漏洞，但把"一个漏洞就完蛋"变成"需要一条链"，攻击成本上升一个数量级。Web 开发里对应的设计：把处理不可信输入的部分隔离到独立的进程/容器/Worker 里，即使被打穿也拿不到主服务的凭据和数据库连接。图片处理、文档转换、用户提交代码的执行——这几类最该做隔离。
64. A 0-click exploit chain for the Pixel 9 Part 3: Where do we go from here?
来源：Google Project Zero，2026 年 1 月，三部曲第三篇。
读它解决什么：这条链的收尾与对未来防御方向的讨论。
要点：
- 系列第三部分，标题转向"接下来怎么办"
- 从具体利用转向防御方向的讨论
我的补充：三部曲用两篇讲利用、一篇讲防御方向，这个比例本身表达了 Project Zero 的立场：公开细节的目的是驱动结构性改进。这类文章里的防御讨论通常指向几个方向：用内存安全语言重写（见第 79 条把 Rust 用到基带的例子）、硬件层面的缓解机制（MTE、指针认证）、以及缩小攻击面。值得注意的是"打补丁"通常不在其中——因为在同一个攻击面上，补丁的速度赶不上新漏洞被发现的速度。
65. A look at an Android ITW DNG exploit
来源：Google Project Zero，2025 年 12 月。
读它解决什么：一个在野（in-the-wild）被实际使用的 Android 漏洞利用分析。
要点：
- 分析一个在野的 Android DNG（相机原始图像格式）漏洞利用
- "ITW" 表示这是真实攻击中捕获的样本，不是研究者构造的
我的补充：在野利用分析是最有价值的一类安全情报，因为它告诉你攻击者实际在用什么，而不是理论上可能用什么。DNG 是相机原始图像格式，又是一个"复杂格式 + 自动解析"的例子（和第 62 条的音频解码同构）。这条对防御方的实际用法：如果你的产品处理用户上传的图像，RAW 和其他冷门格式应该直接拒绝——支持它们的收益极低（用户量很小），而解析库的攻击面极大。白名单允许的格式，别用黑名单禁止危险格式。
66. From Chrome renderer code exec to kernel with MSG_OOB
来源：Google Project Zero，2025 年 8 月。
读它解决什么：从浏览器渲染进程提权到内核的路径。
要点：
- 从 Chrome 渲染进程的代码执行提升到内核权限
- 利用点与
MSG_OOB（socket 的带外数据）相关
我的补充：这是浏览器沙箱逃逸的标准形态：渲染进程本身被限制得很死（无文件系统、无网络、受限的系统调用），但它仍然能调用一部分内核接口，那些接口就是攻击面。MSG_OOB 这种冷门的 socket 特性正是典型——很少被使用，所以测试覆盖低、代码质量差。给系统加固的启示：seccomp 过滤应该是白名单（只允许明确需要的系统调用），不是黑名单。这条原则在容器安全里同样成立：Docker 的默认 seccomp 配置已经拦掉了大部分冷门系统调用，自定义 profile 时别为了省事放宽它。
信息泄露与缓解机制绕过
67. Defeating KASLR by Doing Nothing at All
来源：Google Project Zero，2025 年 11 月。
读它解决什么：内核地址随机化（KASLR）如何在"什么都不做"的情况下被击破。
要点：
- 绕过 KASLR，标题强调不需要主动做任何事
- KASLR 的作用是随机化内核地址以阻碍利用
我的补充：KASLR 的价值完全建立在"攻击者不知道内核在哪"之上，所以任何地址泄露都让它归零。标题里"什么都不做"通常意味着某个默认行为已经把信息交出去了（时序侧信道、可预测的分配模式、某个接口直接返回了指针值）。这里有个对所有安全设计都适用的教训：依赖保密的缓解机制是脆弱的——它不修复漏洞，只是抬高门槛，而门槛可能被一个不相关的信息泄露一次性抹平。所以给"信息泄露"类漏洞定级时，要看它泄露的东西是否为其他缓解机制的前提。
68. Pointer leaks through pointer-keyed data structures
来源：Google Project Zero，2025 年 9 月。
读它解决什么：以指针为键的数据结构如何间接泄露地址信息。
要点：
- 通过以指针作为键的数据结构泄露指针值
- 属于间接的信息泄露路径
我的补充：这类泄露特别隐蔽，因为没有任何代码把指针打印出来——泄露来自可观测的副作用：哈希表用指针算哈希，于是遍历顺序或冲突模式反映了指针的位数；或者迭代顺序暴露了分配地址的相对关系。这个模式在高层语言里也有对应物：用对象地址或自增 ID 做键，会泄露不该泄露的信息。最常见的实例是数据库自增主键放在 URL 里——它泄露了记录总量和创建顺序，还让遍历变得容易。用 UUID 或不透明的外部 ID 是标准做法，理由和这条是同源的。
69. Breaking the Sound Barrier, Part II: Exploiting CVE-2024-54529
来源：Google Project Zero，2026 年 1 月。
读它解决什么：一个具体 CVE 的利用过程分析（音频相关）。
要点：
- CVE-2024-54529 的利用分析，系列第二部分
- 与音频子系统相关（承接 "Sound Barrier" 系列）
我的补充：注意这个 CVE 编号是 2024 年的，而利用分析发表在 2026 年——这个时间差是常态，也是 Project Zero 的披露政策使然（补丁发布后一段时间才公开细节）。对防御方的含义很实际：补丁发布到利用细节公开之间的窗口，就是你必须打完补丁的时间。细节一公开，利用门槛立刻下降。所以补丁管理的 SLA 不该按"漏洞有多严重"定，而该按"细节什么时候会公开"定——而后者通常是可预期的。
Windows 平台研究
70. Windows Exploitation Techniques: Winning Race Conditions with Path Lookups
来源：Google Project Zero，2025 年 12 月。
读它解决什么：Windows 上如何通过路径查找赢得竞态。
要点：
- Windows 利用技术，主题是借路径查找赢得竞态条件
- 涉及文件系统路径解析的时序
我的补充：这是经典的 TOCTOU（检查时到使用时）问题：程序先检查路径（"这个文件安全吗"），再打开它，而两步之间攻击者把路径换成了别的目标（符号链接、junction、重解析点）。Windows 的路径解析比 POSIX 更复杂（设备命名空间、8.3 短名、多种重解析点），可利用的窗口更多。防御原则通用：用句柄而不是路径——打开一次拿到句柄，之后所有操作基于句柄，路径就不会在中途被替换。这条在写任何处理外部指定路径的代码时都适用，包括备份脚本、日志轮转、临时文件处理这类看起来无害的工具（它们经常以高权限运行，正是提权的理想目标）。
71. Bypassing Administrator Protection by Abusing UI Access
来源：Google Project Zero，2026 年 2 月 12 日，James Forshaw。
读它解决什么：Windows 的管理员保护机制如何被绕过，切入点是 UI 访问权限。
要点：
- 绕过 Windows Administrator Protection，路径是滥用 UI Access
- 作者在这轮研究中共找到 9 个绕过（均已修复），本文讲其中 5 个的共同根因
- 文中指出 UI Access 长期是 UAC 中被低估的弱点
我的补充：UI 层作为提权通道是个容易被忽视的方向。如果一个低权限进程能给高权限进程的窗口发送输入事件，它就能让后者代它做事——这就是经典的 shatter attack，Windows 后来引入 UIPI（用户界面权限隔离）来阻止。同一个模式在别处也有：X11 默认允许任意客户端截屏和注入按键（这是 Wayland 取代它的主要安全动机之一），Android 上辅助功能权限被恶意应用滥用也是这个形态。另外"9 个绕过，5 个同一根因"这个数字本身很有信息量：逐个修补症状而不消除根因，就会一直有新的绕过。审视权限模型时，记得把"能不能操作别人的界面"算作一种权限。
顺带一个背景：Windows 的权限边界一直尴尬——UAC 历史上就不被微软视为安全边界（官方定位是"便利功能"），所以"绕过 UAC"长期不算漏洞。对管理终端的人的结论不变：别把"有管理员保护"当成允许用户持有本地管理员权限的理由，最小权限才是根本。
72. The Windows Registry Adventure #7: Attack surface analysis
来源：Google Project Zero，2025 年 5 月，Windows 注册表系列第七篇。
读它解决什么：想看一次系统性的攻击面分析是怎么做的，对象是 Windows 注册表。
要点：
- Windows 注册表研究系列的第七篇，主题是攻击面分析
- 该系列共有八篇以上，从历史背景、文件格式、内核对象一路写到实际利用
我的补充：这个系列值得作为**"如何系统研究一个大型子系统"的范本**来读，注册表本身你大概不需要关心。它的推进顺序很典型：先搞清历史与设计意图 → 再摸清数据格式 → 再看内核里的对象模型 → 然后才是攻击面枚举与利用。绝大多数人跳过前三步直接 fuzz，所以只能找到浅层问题。攻击面分析这一篇的方法可以直接迁移：列出所有信任边界的入口点，标注每个入口能被谁触达、带什么权限、处理什么格式——这份清单做出来之后，你对自己系统的风险分布会有和之前完全不同的认识。我给这个博客做审计时也是先列清单：哪些 Pages Functions 接受外部输入、各自的输入形态是什么、有没有绑定 R2 或密钥。
73. A Deep Dive into the GetProcessHandleFromHwnd API
来源：Google Project Zero，2026 年 2 月。
读它解决什么：一个 Windows API 的深入分析，展示单个 API 如何成为攻击面。
要点：
- 深入分析
GetProcessHandleFromHwnd这一 Windows API - 该 API 从窗口句柄获取进程句柄
我的补充：这个 API 做的事本身就跨越了边界——从"我能看到这个窗口"推导出"我能拿到这个进程的句柄"，而进程句柄是后续一切操作的钥匙。这类"看起来无害的查询接口"是提权研究的富矿：设计时的意图是便利，但它把一种低权限能力（枚举窗口）转换成了另一种高价值能力。设计 API 时值得自问的一句：这个接口是否把一种权限转换成了另一种更强的权限。在 Web 后端做权限设计时同样适用——很多越权漏洞的形态就是"用能查 A 的权限，间接拿到了 B 的数据"。
研究方法与团队实践
74. On the Effectiveness of Mutational Grammar Fuzzing
来源：Google Project Zero，2026 年 3 月。
读它解决什么：语法感知的变异式 fuzzing 到底多有效。
要点：
- 评估变异式语法 fuzzing 的有效性
- 属于方法论评估而非具体漏洞
我的补充：fuzzing 有两条路：纯随机变异（快，但对有严格语法的输入几乎全被解析器早期拒绝，覆盖不到深层逻辑）和语法感知生成（能生成合法输入所以走得深，但受语法定义的约束，可能永远探不到解析器的容错分支）。变异式语法 fuzzing 是两者的结合。可迁移到日常开发的是属性测试（property-based testing）这个同源思路：与其手写几个测试用例，不如描述输入的形状让工具生成大量样例并检查不变量。对解析器、序列化、状态机这类代码，属性测试发现边界 bug 的效率远高于人工列用例。
75. Thinking Outside The Box [dusted off draft from 2017]
来源：Google Project Zero，2025 年 12 月发表的一份 2017 年旧草稿。
读它解决什么：漏洞研究中的思维方式，一份被搁置多年才发表的手稿。
要点：
- 2017 年写就、2025 年才发表的草稿
- 主题是漏洞研究中的跳出框架思考
我的补充：一份八年后仍值得发表的草稿说明一件事：方法论比具体技术细节保值得多。2017 年的具体漏洞今天全部无关了，但"怎么找漏洞"的思考方式还成立。这也是我编排这整个资料库时的判断依据——各卷里我优先收的是讲原理和方法的内容，而不是讲某个版本某个配置的（编程卷第四卷那种时效性强的内容我专门挑了会持续更新的来源）。
76. Welcome to the new Project Zero Blog
来源：Google Project Zero，2025 年 12 月。
读它解决什么：Project Zero 博客迁移的公告。
要点：
- 博客从 Blogspot 迁移到
projectzero.google独立域名 - 属于站点变更公告
我的补充：把这条收进来是有实际理由的：旧的 googleprojectzero.blogspot.com 链接现在会 301 到新域名。如果你有收藏夹、内部 wiki、或者自动化脚本引用了旧地址，需要更新——重定向今天有效，不保证永远有效。我在抓这批资料时就撞到了这个 301。顺带一个更普适的提醒：引用外部研究时，重要的内容值得自己留一份归档（Wayback Machine 或本地 PDF），因为安全研究博客的域名和平台变更相当频繁，这个库里就有好几个来源在近两年换过地址（编程卷里的 Python Insider 也搬过家）。
浏览器厂商的响应实践
77. Behind the Scenes: Fixing an In-the-Wild Firefox Exploit
来源：Mozilla Security Blog，2024 年 10 月。
读它解决什么：厂商在发现在野利用后的应急响应过程。
要点：
- Mozilla 修复一个在野 Firefox 利用的幕后记录
- 视角是厂商的响应流程而非漏洞技术细节
我的补充：这类幕后记录对做应急响应的人价值很高，因为公开的复盘太少了。可以关注的是时间线：从收到情报、复现、定位、开发补丁、到推送给几亿用户，每个环节花了多久。浏览器厂商的优势是有成熟的快速推送渠道（可以在几小时内发出补丁），这个能力本身是长期投入的结果。给自己团队的对照问题：如果现在得知你的系统正在被利用，从确认到全量修复需要多久？ 如果答案是"要等下个发布窗口"，那这个流程在真正的应急面前是不够用的。
78. Firefox Security Response to pwn2own 2025
来源：Mozilla Security Blog，2025 年 5 月。
读它解决什么：厂商如何应对 Pwn2Own 竞赛中被公开利用的漏洞。
要点：
- Mozilla 对 Pwn2Own 2025 中 Firefox 相关漏洞的响应
- Pwn2Own 是有厂商配合的公开攻防竞赛
我的补充：Pwn2Own 这类有奖竞赛是漏洞经济里健康的一端：研究者拿到合法报酬、厂商在受控环境下拿到完整利用链、漏洞不流向灰市。厂商在竞赛后往往能在几天内发布补丁，因为拿到的是可复现的完整利用而不是模糊的报告。对任何有产品的团队的启示：建立漏洞报告渠道并且真的响应它（security.txt、明确的邮箱、承诺的响应时限）。没有渠道的后果不是没人找到漏洞，而是找到的人不知道该告诉谁——最好的情况是他们放弃，最坏的情况是流向别处。
79. Bringing Rust to the Pixel Baseband
来源：Google 安全博客，2026 年 4 月。
读它解决什么：把内存安全语言用到手机基带这样的底层组件上。
要点：
- 在 Pixel 的基带（baseband）中引入 Rust
- 基带处理蜂窝网络协议，是远程攻击面
我的补充：基带是移动设备上最值得优先加固的攻击面：它处理来自空口的数据（也就是任何能架起伪基站的人都能发给你的输入）、传统上用 C 写、常常运行在独立处理器上且缺少现代缓解机制。用 Rust 重写它是**从"修漏洞"转向"消除漏洞类别"**的典型动作，方向上和第 64 条那个防御讨论一致。可迁移的判断标准：当某个组件满足"处理不可信输入 + 用内存不安全语言写 + 历史上反复出漏洞"这三条时，重写的性价比就超过继续打补丁。这也是 编程卷第一卷第 9 条（CPython 引入 Rust）背后的同一个逻辑。
80. Rapidly Leveling up Firefox Security
来源：Mozilla Security Blog，2024 年 4 月。
读它解决什么：一个大型项目如何系统性地提升安全水位。
要点：
- Firefox 安全能力的系统性提升
- 关注的是整体工程举措而非单个漏洞
我的补充：这类文章讲的是安全的工程化，比单个漏洞分析更值得管理者读。大型项目提升安全水位的手段基本是固定的几样：进程隔离与沙箱收紧、把高风险模块换成内存安全语言、持续 fuzzing 接入 CI、以及漏洞奖励计划。这四项的共同点是都不针对具体漏洞，都是降低整类问题的发生率或影响。做安全规划时的一个实用检查：如果你的安全投入清单里全是"修复已知漏洞"，那你只有应急能力没有改进能力——下一年的漏洞数量不会变。
本卷小结
三个带走的结论：
- "影响有限"的漏洞是利用链的零件。 一个地址泄露让 KASLR 归零（第 67 条），一个 UI 权限成为提权通道（第 71 条）。定级时要问的不是"这个漏洞本身能做什么"，而是"它是不是别的缓解机制的前提"。
- 沙箱有效，但只是抬高成本。 零点击链里逃逸沙箱要花掉一个完整漏洞（第 63 条）。Web 侧对应的做法是把处理不可信输入的部分隔离出去——图片处理、文档转换、用户代码执行这三类最该做。
- 补丁窗口是可预期的。 细节公开的时间点由披露政策决定（第 69 条那个 CVE 从补丁到细节公开跨了一年多）。补丁 SLA 该按"细节何时公开"来定，而不只按严重性。
上一卷： ← ③ 认证、会话与令牌 · 下一卷： ⑤ 防御、泄露与事件响应 →