GrapheneOS 修复了被 Google 忽略的关键 Android VPN 泄露漏洞
在移动安全领域,“始终开启的 VPN”(Always-On VPN)的承诺通常是隐私意识强的用户最后的防线。其设计初衷是确保除非数据被封装在安全隧道内,否则绝不会离开设备。然而,最近在 Android 16 中披露的一个漏洞证明,即使是这些严格的锁定保护也可以被绕过,从而可能将用户的真实公网 IP 地址暴露给远程服务器。
虽然该漏洞已向 Google 报告,但该公司拒绝发布补丁,将其归类为“不予修复”(Won't Fix)。在这一举动凸显了主流 Android 与经过安全加固的分支版本之间不断分化的优先级,GrapheneOS 已在最新版本中介入并修复了该泄露问题。
泄露的原理:QUIC 与 system_server
该漏洞由安全研究员 "lowlevel/Yusuf" 发现并披露。问题的根源在于 Android 网络栈中引入的一项新功能,旨在处理 QUIC (Quick UDP Internet Connections) 会话的拆除。
在正常情况下,当一个 UDP 套接字被销毁时,系统可能希望优雅地终止会话。为了实现这一点,Android 引入了一个 API,允许应用程序注册特定的 UDP 负载(payload)以便在套接字销毁时发送。
根据技术分析,该漏洞通过以下机制显现:
- 任意负载注册:具有标准
INTERNET和ACCESS_NETWORK_STATE权限的应用程序可以在system_server进程中注册任意 UDP 负载。 - 特权传输:当应用程序的 UDP 套接字随后被销毁时,具有高度特权的
system_server会传输存储的负载。 - VPN 绕过:由于
system_server运行在提升的网络特权下,它不受标准 VPN 路由限制的约束。因此,数据包被直接通过设备的物理网络接口发送,完全绕过了“无 VPN 时禁止连接”的锁定模式。
在一次使用运行 Android 16 的 Pixel 8 进行演示的过程中,研究员展示了应用程序可以成功地将设备的实际公网 IP 地址泄露给远程服务器,即使在启用了 Proton VPN 且处于锁定模式下也是如此。
Google 的回应:“不予修复”
或许比技术缺陷本身更具争议的是 Google 对该报告的回应。尽管研究员辩持认为任何具有基本权限的应用程序都可以泄露识别性的网络信息,但 Google 的安全团队将该漏洞归类为:
- "Won't Fix (Infeasible)"
- "NSBC" (Not Security Bulletin Class)
Google 坚称该问题未达到包含在 Android 安全公告中并授权在 2026 年 4 月 29 日进行公开披露的门槛,且未提供任何修复方案。
GrapheneOS 的介入
GrapheneOS,一个主要为 Pixel 设备开发的以隐私为中心的操作系统的 OS,做出了快速响应。在版本 2026050400 中,该项目通过完全禁用 registerQuicConnectionClosePayload 优化功能,中和了该攻击向量。
除了这项特定的修复,该更新还集成了 2026 年 5 月的 Android 安全补丁级别,更新了多个分支的 Linux 内核(6.1, 6.6, 和 6.12),并实施了对动态代码加载(Dynamic Code Loading)的进一步限制。
社区观点与技术批判
该泄露问题的披露引发了技术社区的大量辩论,特别是关于 Google 拒绝修复它的问题。一些观察者指出,此类“泄露”可能并非偶然,一位评论者指出:
"Just like manifest v3, it's not in their best interests to disallow snooping。 It hurts their business model。"
从更深层的技术角度来看,一些分析师认为,该漏洞不仅代表了一个简单的泄露,更代表了 Android 沙箱机制的失效。一位社区成员指出,该漏洞涉及一个进程在没有适当权限检查的情况下,为操作系统代为发送一个任意字节数组,这在他们看来等同于“权限提升”和“应用程序沙箱逃逸”。
原生 Android 用户 Mitigiation(缓解措施)
对于无法切换到 GrapheneOS 但希望在原生 Android 上缓解此风险的用户,研究员建议通过 Android Debug Bridge (ADB) 进行手动规避。用户可以禁用 close_quic_connection DeviceConfig 标志。然而,这只是一个临时措施,需要开发者权限,并且可能会被未来的系统更新覆盖。
这一事件有力地提醒了“标准”安全与“加固”安全之间的差距。虽然原生 Android 提供了一套广泛的工具,但 GrapheneOS 继续证明了为什么对于那些其威胁模型要求绝对网络隔离的用户来说,专门的、安全第一的方法是必要的。