SDC2025 议题回顾 | 你尽力了吗——25 年后的再追问

很高兴有机会在这里和大家交流。原本这次演讲早两年就该来，但当时工作特别多，所以一直未能成行。今天正好有这个机会，我把为内部培训准备的一个议题整理出来与大家分享——原稿的幻灯片很多（约150页，原计划两到三个小时），今天我压缩、精简为大约40分钟的内容：5分钟开场，接下来我会加快语速，用约30分钟讲若干案例与复盘，最后做结论与展望。

本议题的出发点是复盘。过去我更多以漏洞的类别来组织汇报——把漏洞分门别类、逐一分析；但这两年我更倾向于把漏洞当成一个复盘对象：从不同的角色和环节去追问“到底哪个环节出了问题、应如何改进”。从复盘视角出发，往往会把责任与改进点具体化，因此我把漏洞复盘至少分为五个视角：系统架构、开发、QA（测试）、SDR（安全响应/处置流程）、以及研究员视角。今天讨论的大部分漏洞来自苹果内核相关实现，但并不是要针对苹果——只是这两年我对苹果实现研究较多，所以案例以此为主。

下面先做一个很简短的自我介绍与来时路回顾：我叫王宇。我列了一 张之前工作的列表，主要与演讲相关，包括一些研究成果。最早可以追溯到2014年，那年是我第一次在Black Hat USA上演讲。今年2025年，我也有一个议题，2025年我也有一个议题，所以就是一个来时路的感觉。

先讲个小故事。这个小故事是我刚毕业的时候，去的第一家公司。当时我的办公室里，有一个L型的办公桌。在桌上打印了很多A4纸，上面有我的待办事项，还有一些非常值得阅读的论文。在L型桌子的正面，我打印了一页纸，上面写着XCON那本书《网络渗透技术》的序言。

我今天甚至把这本书带来了。这本书非常经典，这是2005年4月的第一版。序言中讲得很有趣，中国的安全领域一直在认真地做事，但在2005年时，没有人登上过Black Hat大会。登上Black Hat的人，一个都没有。所以，回看当年写的那张纸，其实我做到了。2014年，那一年是第一次有中国人去Black Hat USA演讲。当时是我和TK老师去的。如果认真算的话，Black Hat第一个演讲的中国人可能是安恒的范渊老师，范总。我前两天和范总聊到这个事，他当时是以美国高校的身份去的。

我办公桌侧面贴的那张纸，其实就是四哥的《你尽力了吗？》。所以借着今天这个机会，把两件事都复盘一下。

下面进入正文：从五个复盘视角出发，先给出总体观点：安全事件常常暴露出“没有经验”或“没尽力”的问题，很多失误并非偶发，而是在流程、架构或实现上留下的可复现缺陷。接下来按案例讲述我关注到的若干典型问题与教训。

（注：以下为演讲提要，内容有删减）

一、从系统架构/模块设计的复盘：IOMobileFramebuffer（显卡相关）

第一个案例来自显卡子系统，模块名为IOMobileFrameBuffer（苹果在移动平台对 GPU frame buffer 的实现）。这是一个负责把 GPU 渲染数据管理与暴露给系统的关键模块。我的统计显示，从该模块开始到 2025 年，共公开了 16 个漏洞，其中若干非常著名（包括被越狱工具与 APT 利用的案例）。这个模块在 2021–2022 年间漏洞高发期尤为引人注目。

原因是什么？关键点在于：2020 年该模块进行了大规模重构，但重构时安全性考虑不足。重构带来新接口与新路径，未充分评估或缓解安全风险，结果在 2021 年成为攻击的高峰期，许多 APT 与越狱工具都利用了该模块的缺陷。苹果后来在 2021 年 10 月开始缩减攻击面，把一些函数移到更底层（例如固件层面），从某种角度算是一种变相的深度防御——把暴露面往更难触达的位置移。但关键反思是：模块重构时架构与安全设计的缺位，会带来长期的灾难性后果，模块设计者与重构负责人应承担更高的责任。

二、从实现细节/驱动实现的复盘：蓝牙与固件路径

第二个案例来自蓝牙。

我最初报告的一个漏洞，苹果声称已修复，但我验证后发现补丁可以被绕过，漏洞依然存在。

当时我之所以研究蓝牙，是因为想研究汽车通信。疫情期间被困在家，只能从手边的苹果设备入手，去分析蓝牙和 WiFi 的攻击面。

当时看到一篇文章叫《Hacking iOS Bluetooth》，内容并不是真正的攻击，而是介绍了一个修改蓝牙名称的小工具。但它附带了一张非常完整的调用栈图——展示了蓝牙请求从发出到固件处理的全过程。那张图让我印象深刻，因为它揭示了系统的全部调用链。

我注意到，在进入内核的第一个函数RunAction中，系统为整个通信流程加了一把“全局大锁”——IOCommandGate。

进入内核时上锁，传输前解锁。

这种设计看似简单，但问题在于锁的粒度太大，性能低且极易出错。另外，这个调用栈暴露出了一个更加严重的问题 —— 锁对于数据与状态机的保护范围存在设计缺陷。

这类架构问题从 2008 年延续到今天，属于“十年前的错误在十年后重演”的典型案例。

接下来是 WiFi 的两个漏洞。

第一个是调试接口问题。

苹果工程师为了方便，在关键函数中手写了用户态与内核态的内存拷贝逻辑，而没有使用系统提供的标准接口。

结果判断条件被绕过，导致任意地址可写。

这种错误不该出现在核心模块里——这是典型的“没有尽力”的问题。

第二个漏洞出现在 WiFi 的 PCIe 模块。

系统的内存分配、初始化和返回数据分别由三个函数完成，但之间没有加锁。

只要调用顺序被打乱（例如从 1-2-3 变成 1-3-2），就会导致严重的内存泄漏或任意代码执行。

这其实是多人协作下常见的逻辑失序问题，也是复盘中反复出现的一个根源：流程复杂但责任不清，导致程序员在实现上“没尽力”。

三、从 QA（测试）与变更管理的复盘：数据修改、未充分测试的“纯数据变更”

这里有两个有代表性的案例：

1.“只改数据，不改代码”引发的越界问题（MacOS Sonoma）——某次修改仅是把日志格式中一个终止符（原来是-）改为更“好看”的字符串（比如WLAN Log Reserved），没有修改代码逻辑，开发、评审与测试都认为“代码没改、无需测试”。

但实际上代码里是严格匹配那个字符作为终止符的；数据的改动改变了判定，让宿主程序无法正确结束，最终触发了越界问题。教训：任何数据的改变都可能改变程序语义，不能在评审或测试中被忽视；数据与代码的边界往往比我们想象的脆弱。

1.补丁只考虑“小于情形”，忽视“大于/等于情形”——在 GPU 初始容量（initial capacity）相关的一个漏洞修复中，补丁只增加了“如果小于最低要求就报错”的判断，但对“大于等于”的边界未做充分考虑，结果修复后仍然存在触发路径，需要额外的迭代修复。教训是：补丁设计与测试必须覆盖完整的输入域与边界条件，修复时要以“攻击者视角”思考未覆盖的情况。

此外还有 CVE 流程与描述上的问题，例如某次本地崩溃被标注为“可能导致拒绝服务（DoS）”，而安全社区长期对本地 DoS 是否应分配 CVE 有争议。这里反映出组织内部对漏洞严重性、描述与分类的一致性不足，影响沟通与资源分配。

四、从安全响应（SDR）与沟通流程的复盘

在我提交给厂商（以苹果为例）的若干报告中，反复遇到如下痛点：

◆补丁发布与描述不一致，导致外界难以评估真实影响或在补丁发布后仍能被绕过。

◆不同团队修出不同补丁版本（例如同一漏洞出现两套修复逻辑），反映修复流程缺少统一标准与跨团队协调。

◆Beta 系统的漏洞处理与 CVE 授权流程脱节：苹果对 Beta 系统漏洞的 CVE 给予有条件的处理，导致一些在 Beta 发现但在正式版发布前的漏洞没有 CVE 编号。

总体上，SDR 流程需要更重视外部研究员的报告，及时与研究者沟通补丁设计考量，并在发布前进行统一的安全评估与回归测试。

五、从研究人员角度的自我反思

作为研究员，我也有自己的不足与成长路径要分享。早年我在字体引擎（如 Win32k / TrueType）做了大量逆向与分析工作，甚至在 2014 年在 Black Hat 讲过相关内容：字体渲染涉及一个完整的指令集及虚拟机，复杂且容易出问题。我做了大量静态逆向的工作，但被 Google Project Zero 的  j00ru 用 Fuzzing 大量发现漏洞的实践狠狠地提醒：静态与动态、逆向与模糊测试应该结合。单一方法无法覆盖全部路径，研究人员要尽力在广度（路径覆盖）和深度（理解实现细节）上都投入。

此外，行业里很多非常优秀的人也会在复杂实现上犯错（例如某些 user-mode callback 导致的竞态问题被误判为死代码），这说明漏洞分析往往需要结合对实现微妙行为的深刻理解，以及充分的动态验证与可利用性证明。

我也想提到一位同行 Jiska（Secure Mobile Networking Lab）及其团队的工作：他们开发了较为系统的漏洞挖掘工具，采用 SMT 等技术进行约束求解，发现了许多深层问题；但我也提醒一句：方法再多，路径覆盖不足时仍会漏掉问题。工具与方法固然重要，但最终还是要靠对路径覆盖的关注与实际验证。

结论与建议（简短）

我从三个角度做一个简短总结：

1.保持谦虚：即便是领域内的专家，面对复杂实现也可能得出错误结论；谦虚促使我们更谨慎地验证假设、更多地做动态测试与对抗验证。

2.尽力而为：不论是架构师、开发者、测试还是响应团队，“尽力”体现在使用标准接口、覆盖边界条件、保证补丁测试完整、以及在变更中重视数据语义。很多漏洞并非难以想象，而是可以通过细致的工程习惯避免。

3.保持热情：安全研究与产品安全需要持续投入与热情，没有热情很难做长久深入的工作，但光有热情还不够，还要把“热情”转化为严谨的工程实践。

最后做一个轻松的收尾：我请“四哥”帮我做了一个结尾小彩蛋，感谢各位的聆听。希望今天的几个案例与复盘视角，能给大家一些可操作的启发：从架构到实现，从测试到应急响应，每一环都值得我们认真复盘与改进，谢谢大家。