【卷卷观察】一条音频文件就能接管你的手机——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链不到一天。配图建议3RET 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。技术债越积越多直到某天爆发一个大的。配图建议5Android安全层次图——展示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评论