跳转至

A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens

Ch12.083 A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens

📊 Level ⭐⭐ | 5.3KB | entities/a-0-click-exploit-chain-for-the-pixel-10-when-a-door-closes-a-window-opens-1.md

核心要点

相关实体

→ 原文存档

深度分析

mmap handler：被忽视的内核提权战场 这个 VPU 驱动的 mmap 处理函数中的 bug 堪称"教科书级的浅层漏洞"：没有复杂的 race condition，没有混淆的内存损坏——仅仅是一个参数校验缺失。remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, ...) 中，pfn 由设备的寄存器区域物理地址计算而来，但调用者可以通过指定大于实际寄存器区域的 VMA 大小，让 remap_pfn_range 将超过该区域的物理内存映射到用户空间。Project Zero 的评注一针见血：当你能够指定映射大小时，你实际上拥有了对物理内存的任意读写能力。 Pixel 系列"固定内核物理地址"的长期工程权衡 Project Zero 在 2025 年 11 月发现 Pixel 上的内核物理地址是固定的（不受 KASLR 影响）——这一设计决策从性能或功耗角度可能是合理的，但它意味着一个 mmap 漏洞可以直接绕过 KASLR 这一重要的运行时保护。攻击者不需要扫描内存来定位内核，只要知道 VPU 寄存器区域和内核镜像之间的固定偏移量，就可以直接重写任意内核函数。 Do Not Assume Drivers Are Secure: Chips&Media 案例的深层教训 VPU 驱动和 BigWave 驱动由同一组开发者维护，当 Project Zero 向这些开发者报告 BigWave 漏洞时，曾希望他们能主动审查其他驱动程序中是否存在类似问题。然而 5 个月后，VPU 驱动中出现了同样"浅显"的 mmap bug。这揭示了一个普遍现象：驱动程序的安全开发缺乏系统性方法论，通常是"发现一个漏洞，修复一个漏洞"，而非对整个代码库进行主动安全审计。硬件厂商通常将驱动开发视为硬件功能的薄封装层，而安全社区则将驱动视为攻击面——这两种视角之间的差距是 Android 生态系统中持续存在的攻击面根源。 修复周期的进步：71 天 vs 90+ 天 Project Zero 特别指出这是他们报告的 Android 驱动 bug 中首次在 90 天内修复，最终用时 71 天。这说明 Android VRP（漏洞奖励计划）和芯片厂商之间的协调机制正在改善。但值得注意的是，这仍然是 71 天——在 AI 辅助漏洞发现的工具越来越强大的背景下，71 天的修复窗口仍然为有动机的攻击者提供了充足的利用时间。

实践启示

  • 驱动开发中的 mmap handler 必须严格校验 VMA 大小不超过实际硬件寄存器区域：在调用 remap_pfn_range 之前，增加显式的大小比较检查，这是最简单有效的修复方式。
  • 不要依赖 KASLR 作为唯一的内核保护：如果驱动存在 mmap 漏洞，KASLR 的固定偏移设计会使内核完全暴露。纵深防御需要同时考虑：驱动代码安全 + 内核内存布局随机化 + 物理内存隔离。
  • 芯片厂商需要建立系统性的驱动安全审计机制：在发布新芯片/新驱动之前，对所有 mmap、ioctl 和用户-内核数据交换路径进行标准化安全审查，而非等待外部研究者发现。
  • 终端用户的安全建议：Pixel 10 用户应确保安装 2026 年 2 月及之后的安全更新（SPL December 2025 或更早的版本仍存在漏洞）。考虑到该漏洞的利用复杂度极低（5 行代码实现任意内核读写），不应依赖"没人会用这么高级的漏洞攻击我"的侥幸。
  • Project Zero 的负责任披露模式再次展示标杆实践：向厂商报告漏洞、通过 90 天披露期限推动修复、公开详细技术分析以推动整个生态系统改进——这是安全研究社区和厂商之间的正向循环。