【卷卷观察】一条音频文件就能接管你的手机——Pixel 10零点击漏洞链全解析

一句话结论

Google Project Zero的研究员用不到一天时间，从一条恶意音频文件出发，完成了对Pixel 10的完整零点击内核接管。这不是什么科幻剧情，这是2025年真实发生的事。更让人后背发凉的是——第二阶段漏洞，两位研究员审计了不到两小时就找到了。

风控人的噩梦：零点击

我平时做风控相关的工作，整天琢磨的都是"用户做了什么可疑操作"、"这个行为序列是不是异常"。结果零点击攻击直接把我这套逻辑的根基掀了——用户什么都没做。没点链接，没装APP，没授权，手机就被控制了。

你什么都没做错，但你已经被黑了。

就像你家门锁好好的，窗户关着，保安巡逻着，结果发现有人在自来水管里下了毒——你正常喝水就中招了。

Google Project Zero的研究员Seth Jenkins发现的这条漏洞链，攻击入口是Dolby Unified Decoder处理一段恶意音频文件。注意，不是你主动打开一个可疑的音频APP，而是系统在后台自动处理音频数据时就触发了漏洞。你可能在听歌、在刷视频、甚至在接电话，解码器在后台默默工作，恶意代码就已经在执行了。

这就是零点击的含义：不需要你的任何交互。

配图建议2：攻击链流程图——从"恶意音频文件"到"Dolby解码器漏洞"到"内存破坏"到"VPU驱动漏洞"到"内核控制"，用箭头串联，每个节点标注关键信息

攻击链拆解：用自然语言讲一遍

这条漏洞链分两个阶段，我试着把技术细节翻译成人话。

第一阶段：音频解码器里的定时炸弹

你的手机里有个东西叫Dolby Unified Decoder，负责处理音频。不管你放什么声音，它都在后面默默干活。Jenkins发现，当这个解码器处理一段特殊构造的音频文件时，会触发内存破坏漏洞（CVE-2025-54957）。

内存破坏是什么概念？程序在内存里存数据，像图书馆的书架一样，每本书有固定位置。恶意音频文件让解码器往格子里塞数据时，塞错了位置，或者塞超量了，把旁边格子里的东西给覆盖掉了。攻击者精心构造这些"放错位置"的数据，就能劫持程序的执行流。

但这里有个难点。Pixel 10用了Google自研的Tensor G5芯片，这颗芯片引入了一个叫RET PAC的安全机制——返回地址指针认证。什么意思呢？程序调用函数时会有一个"返回地址"，告诉程序"这个函数执行完了，回到哪里继续"。传统的攻击手法就是篡改这个返回地址，让程序跳到攻击者的代码。RET PAC在这个返回地址上加了一把"签名锁"，程序返回时会验证签名，签名不对就不跳转。

这就把很多传统的exploit路径堵死了。

但Jenkins硬是找到了一条新路——一个叫dap_cpdp_init的函数。这个函数在解码器初始化阶段被调用，调用方式恰好绕过了RET PAC的保护范围。具体细节涉及ARM指令集层面的利用构造，硬核到我不打算展开，但核心逻辑一句话就说清楚了：RET PAC守的是函数返回那条路，而Jenkins根本不走那条路，从旁边翻了墙。

第一阶段完成后，攻击者已经在设备上有了代码执行能力，但还在用户态，权限有限。要拿到内核控制权，还需要第二阶段。

第二阶段：两小时找到的内核漏洞

Pixel 9用的是BigWave AV1视频驱动来做第二阶段的提权。这个驱动之前就有已知漏洞，已经被修复了。Pixel 10换了新的硬件，视频处理单元换了新驱动——一个叫/dev/vpu的VPU驱动。

新驱动，新的希望。Jenkins和另一位Project Zero研究员Jann Horn坐下来审计这个新驱动。

不到两个小时，他们就找到了漏洞。

这个漏洞的成因说出来让人想骂人：VPU驱动的mmap handler——处理内存映射的代码——缺了长度验证。mmap让程序直接访问设备内存，按理说驱动得检查请求映射的内存范围合不合法。但这驱动没检查。

没有检查。连要映射多大都没看。

程序说"我要映射这块内存"，驱动就说"好的"，连要映射多大、地址合不合法都不看。这意味着攻击者可以映射任意的物理内存地址，读写内核空间的任何数据。

更离谱的是，内核的物理地址是可预测的，连KASLR都不需要绕过。KASLR把内核在内存里的位置随机化，本来是为了增加攻击难度的，但当攻击者可以直接读写物理内存时，这层随机化直接废了——物理地址又不跟着KASLR走。

两个阶段串起来：恶意音频文件触发解码器漏洞，获得用户态代码执行；然后利用VPU驱动的mmap漏洞，获得内核物理内存的任意读写；最终完全控制内核，也就完全控制了整台手机。

从开始到完整exploit链，不到一天。

配图建议3：RET PAC绕过示意图——对比传统攻击路径（篡改返回地址）和Jenkins的新路径（通过dap_cpdp_init），展示RET PAC的防御范围和绕过方式

"不到两小时"意味着什么

这个"不到两小时"是我觉得最值得深聊的点。

两位顶级研究员审计一个新驱动，不到两小时就发现漏洞，这说明什么？

说明漏洞太明显了。不是什么需要绞尽脑汁才能发现的边角case，是基本的输入验证都没做。mmap handler检查请求长度，这是安全编码的入门级要求，相当于写Web应用要检查用户输入一样基础。

这不是偶然。

更有意思的是，这个新VPU驱动和Pixel 9的BigWave驱动是同一个团队开发的。一个团队，写出了两个有漏洞的驱动。BigWave的漏洞被修了，换了个新驱动，同一批人，同样的安全意识水平，写出同样有问题的代码。

这就是组织问题，不是偶然事件。

这种事我见太多了。一个团队交付了有质量问题的模块，你让他们重写，大概率还是一样的问题。根因不是谁手滑了，而是团队压根没建立安全编码的意识和流程——没有code review的安全检查项，没有静态分析工具的强制卡点，没有安全测试的验收标准。换人不换流程，结果不会变。

补丁只能修一个洞，但墙上全是洞。

配图建议4：对比图——BigWave驱动漏洞 vs 新VPU驱动漏洞，标注"同一开发团队"，暗示组织层面的系统性问题

RET PAC的启示：缓解措施不等于安全

Jenkins绕过RET PAC的过程也值得所有做安全的人想想。

Google在Tensor G5里引入RET PAC，确实提高了攻击门槛。传统的返回地址覆盖攻击路径直接被堵死，攻击者必须寻找新的利用路径。Jenkins花了相当多的时间才找到dap_cpdp_init这条路。

这说明什么？缓解措施（mitigation）是有价值的。它提高了攻击成本，缩小了攻击面，增加了攻击者需要投入的时间和精力。在安全领域，提高攻击成本本身就是有意义的防御手段。

但缓解措施不等于安全。

RET PAC堵死了一条路，但只要代码里还有内存破坏漏洞，攻击者总能找到另一条路。这就好比你给前门加了三道锁，但后门还是虚掩着的。加锁没错，但你不能因为前门锁多了就觉得安全了。

真正的安全应该是：消除内存破坏漏洞本身。用内存安全的语言重写关键组件，或者至少在开发流程中建立足够强的安全保障。RET PAC是好的防御层，但它不应该成为你唯一的希望。

Google自己也明白这一点。Project Zero在报告中明确建议，Android生态需要的不是更多的补丁，而是系统性的安全编码实践。

Android生态的安全债务

这个问题比Pixel 10这一个漏洞大得多。

Android设备的内核里有大量的vendor驱动——芯片厂商、设备厂商提供的各种硬件驱动。这些驱动的代码质量参差不齐，很多厂商的安全意识远远不够。而且这些驱动运行在内核态，一旦有漏洞，影响是整个系统。

Dolby的解码器是这样，VPU驱动也是这样。这些第三方组件通常不是Google自己开发的，但它们运行在Android系统的最底层，拥有最高的权限。

这是Android生态的结构性问题：Google对AOSP核心代码的安全把控越来越强，但vendor驱动这个巨大的攻击面，安全水平完全取决于各个供应商的自觉。

而现实是，很多供应商的安全自觉性堪忧。赶交付进度、压成本、快速迭代，安全永远排在后面。等到漏洞被发现、被利用，再打补丁。补丁打完了，下一个漏洞又被发现。循环往复。

这跟我在工作中看到的很多质量债务问题一模一样：业务催着上线，安全/质量往后排，出了问题救火，救完火继续赶下一个deadline。技术债越积越多，直到某天爆发一个大的。

配图建议5：Android安全层次图——展示AOSP核心（安全加固）vs Vendor驱动（安全债务）的对比，用颜色深浅表示安全水平差异

Google的修复速度在进步，但还不够

说句公道话，Google这次的修复速度确实在提升。从漏洞报告到修复推送，用了71天，首次低于90天的标准线。

71天对于内核级漏洞来说，已经算快的了。但如果你换个角度想：从漏洞被发现到被修复，中间有71天的时间窗口。在这71天里，如果有人已经掌握了这个漏洞（毕竟Project Zero发现的漏洞不一定是第一个发现的），那他们有71天的时间可以利用。

而且Project Zero给厂商的修复期限是90天。也就是说，业界认为90天内修复一个内核级零点击漏洞是"可接受"的速度。

在风控的视角下，71天的暴露窗口期是不可接受的。任何一条能造成全量用户风险的漏洞，71天的窗口意味着什么？意味着如果你是高价值目标，在这71天里，你完全可能已经被攻击了，而你毫不知情。

不过也要承认，Google在进步。从早期动辄120天、180天的修复周期，到现在71天，趋势是对的。Project Zero的存在本身就是一种压力——让漏洞无处藏身，让厂商不得不更快地响应。

对开发者和技术团队的启示

这件事对普通开发者和安全团队有几个很实在的教训：

第一，输入验证是基本功中的基本功，但基本功恰恰是最容易被跳过的。VPU驱动的漏洞就是缺了长度检查，code review和静态分析都能拦住。如果你的团队在写安全敏感的代码，先把输入验证的checklist建起来。

第二，安全是组织能力，不是个人能力。同一个团队写出两个有漏洞的驱动，说明问题不在某个程序员身上，而在团队的流程和意识上。code review要不要检查安全性？有没有安全测试用例？上线前有没有经过安全审计？这些流程性的东西才是根因。

第三，缓解措施和根因修复是两件事。RET PAC提高了攻击成本，是好事。但不要因为有RET PAC就放松了对内存安全的要求。每一层防御都有被绕过的可能，真正要做的是减少漏洞本身。

第四，第三方组件是最大的盲区。Dolby解码器、vendor驱动，这些你不太能直接控制的代码，往往是最脆弱的环节。如果你是平台方，对第三方组件的安全准入门槛要提高。如果你是使用者，要意识到这些组件的风险。

配图建议6：行动建议信息图——针对开发者、安全团队、平台方的具体建议，简洁明了

我的判断

这条漏洞链的技术水平很高，但它暴露的问题不是技术问题，是工程管理和生态治理问题。

一个不到两小时就能发现的内核驱动漏洞，出现在Google旗舰手机的最新芯片上，这本身就说明Android生态的vendor驱动安全审计存在严重的系统性缺失。RET PAC的引入说明Google在芯片层面的安全投入是认真的，但芯片层面的防御挡不住驱动层面的漏洞。

对普通用户来说，保持系统更新、及时安装安全补丁仍然是最有效的防护手段。这条漏洞链已经在最新版本的Android中被修复了。

对开发者来说，每次看到这种"缺少基本输入验证"的内核漏洞，都应该反思一下自己的代码里有没有类似的债务。安全不是加几把锁就完了的事，安全是从第一行代码写对开始的。

Project Zero的工作值得尊敬。他们不只是发现了漏洞，而是用不到一天的时间，完整地证明了一条零点击攻击链是可行的。这种证明比任何安全建议都有说服力——它让你知道，这不是理论风险，这是真实存在的威胁。

参考来源：Google Project Zero研究员Seth Jenkins的漏洞报告，HN社区讨论（337分，156评论）