文章总结： 王宇在SDC2025会议上分享了《你尽力了吗——25年后的再追问》演讲，通过多个操作系统内核漏洞案例，从系统架构、程序研发、质量保证、制度规范、DevSecOps流程建设、安全研究等五个视角分析了安全问题。他指出许多安全事件源于没有经验或没尽力，强调了模块重构时安全设计的重要性，以及测试、补丁设计和安全响应流程中的常见问题。最后，他建议安全从业者保持谦虚、尽力而为、保持热情，并将热情转化为严谨的工程实践。
综合评分： 92
文章分类： 漏洞分析,二进制安全,安全建设,安全运营
SDC2025 议题回顾 | 你尽力了吗——25 年后的再追问
SDC2025
看雪学苑
2025年10月30日 18:00
上海
议题回顾
四哥的经典文章《你尽力了吗》陪伴并激励了几代网安人的成长。尽力，不止是阅读时的情绪共鸣，更应是求索时的知行合一。
本议题将结合作者的研究历程，通过十余个原创的操作系统内核漏洞案例，从系统架构、程序研发、质量保证、制度规范、DevSecOps 流程建设、安全研究等视角与您深入探讨这一话题。
一起来回顾下 王宇 在SDC2025上发表的议题演讲：《你尽力了吗 —— 25 年后的再追问》
演讲嘉宾：王宇
王宇对操作系统内核各领域充满热爱，并曾多次受邀在国际顶尖的工业与学术界安全会议发表演讲，包括：Black Hat USA（2025，2023，2022，2020，2014）、Black Hat Asia（2021，2016）、Black Hat Europe（2020）、ACM CCS（2024，2021）、USENIX Security Symposium（2023）等。2015年至今，王宇还担任 GeekPwn（极棒）、GeekCon 国际安全极客大赛等活动的评委。
*以下为整理后的速记
很高兴有机会在这里和大家交流。原本这次演讲早两年就该来，但当时工作特别多，所以一直未能成行。今天正好有这个机会，我把为内部培训准备的一个议题整理出来与大家分享——原稿的幻灯片很多（约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.保持热情：安全研究与产品安全需要持续投入与热情，没有热情很难做长久深入的工作，但光有热情还不够，还要把“热情”转化为严谨的工程实践。
最后做一个轻松的收尾：我请“四哥”帮我做了一个结尾小彩蛋，感谢各位的聆听。希望今天的几个案例与复盘视角，能给大家一些可操作的启发：从架构到实现，从测试到应急响应，每一环都值得我们认真复盘与改进，谢谢大家。
PPT下载及视频回放
峰会议题PPT及回放视频已上传至【看雪2025 SDC】：https://www.kanxue.com/book-section_list-219.htm
【已购票的参会人员可免费获取】：我方已通过短信将“兑换码”发至手机
兑换方式：
-打开链接https://www.kanxue.com/book-section_list-219.htm
-点击购买课程
-填入兑换码
-提交订单
﹀
﹀
﹀
球分享
球点赞
球在看
点击阅读原文查看更多
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：看雪学苑 SDC2025《SDC2025 议题回顾 | 你尽力了吗——25 年后的再追问》