Android NAT-T keepalive offload bypasses VPN lockdown
211 points
• 4 days ago
• Article
Link
Android 的 Always-on VPN 和 "Block connections without VPN" 设置旨在防止受管应用的数据绕过安全隧道。但平台在处理 NAT‑T keepalive offloading 时存在漏洞，允许普通无特权应用绕过这些保护。利用用于 NAT 遍历的公共 Android API，应用可以请求系统维护 NAT‑T 映射，从而使固定格式的 UDP/4500 数据包直接通过物理网络接口发出。该路径绕开了 VPN lockdown 通常管控的套接字通道，导致设备的真实源 IP 和连接时间泄露到攻击者控制的目的地。
问题根源在于 Android 连接框架中的信任模型崩溃。具体而言，系统的 startNattKeepaliveWithFd 方法未能正确校验文件描述符与 IpSec 资源的对应关系，也未在将数据包下放到硬件或固件前强制执行调用者的生效 VPN lockdown 策略。虽然曾引入资源验证和所有权检查以修复此类问题，但因服务依赖性问题这些改动最终被回退，留下了一个漏洞：无特权应用可以在不证明权限的情况下请求网络 keepalive 。
该漏洞影响运行 Android 12 及更高版本的大量设备，因为大多数当前 Android 衍生产品都包含这一共享框架路径。研究人员在包括 Google Pixel 、 Samsung 和 Nothing 等设备以及多种 Wi‑Fi 芯片组上复现了该行为。由于漏洞依赖标准公共 API，利用不需 root 权限、特殊权限或复杂技巧；一个仅具备基本网络能力的简单应用就能发起并在后台或锁屏等多种设备状态下长时间维持这些 keepalive 包。
尽管对开源应用的静态分析显示对该框架功能的需求并不高，但对于依赖 VPN lockdown 实现身份隔离的用户而言，潜在影响仍然严重。周期性的 keepalive 信号可用于关联网络活动并监测在线状态。为降低风险，平台需进行结构性修复，重新引入严格的资源验证并确保所有 keepalive 请求均受调用者 UID 对应的生效 VPN 与 lockdown 策略约束。在这些修复被实施并验证之前，这些 keepalive 通道仍将成为本应保持仅 VPN 连接设备的潜在泄露点。
Android's Always-on VPN and Block connections without VPN settings are designed to ensure that data from covered applications cannot bypass a secure tunnel. However, a vulnerability in the platform's handling of NAT-T keepalive offloading allows normal, unprivileged applications to bypass these protections. By utilizing the public Android API for NAT traversal, an application can instruct the system to maintain a NAT-T mapping, which leads to fixed-format UDP/4500 packets being emitted directly over the physical network interface. This occurs outside the standard socket path that VPN lockdown policies normally govern, effectively leaking the device's real source IP address and connection timing to an attacker-controlled destination.
The root cause of this exposure is a collapsed trust model within the Android connectivity framework. Specifically, the system's startNattKeepaliveWithFd method fails to properly authenticate the relationship between a file descriptor and an IpSec resource, nor does it enforce the caller's effective VPN lockdown policy before delegating the packet emission to the hardware or firmware level. While resource validation and ownership checks were previously introduced to address these concerns, they were eventually reverted due to service dependency issues, leaving behind a gap where unprivileged applications can request network keepalives without proving their authority to do so.
This vulnerability affects a broad class of devices running Android 12 or later, as the shared framework path is present across the vast majority of current Android-derived shipments. Researchers confirmed this behavior across different hardware, including Google Pixel, Samsung, and Nothing devices, utilizing various Wi-Fi chipset families. Because the vulnerability relies on a standard public API, it does not require root access, special permissions, or complex exploitation techniques. A simple application using basic networking capabilities can initiate these keepalive packets and maintain them through various device states, such as backgrounding or screen locks, for extended periods.
Although a static study of open-source applications suggests low demand for this specific framework feature, the potential impact remains significant for users who rely on VPN lockdown for identity confinement. The periodic nature of the keepalive signal allows for correlation of network activity and presence monitoring. To mitigate this risk, the platform requires a structural fix that reintroduces strict resource validation and ensures that all keepalive requests are gated by the effective VPN and lockdown policy for the caller's UID. Until such repairs are implemented and verified, these keepalive pathways continue to function as a potential leak point for devices expected to maintain strict VPN-only connectivity.
57 comments • Comments Link
• Google 将 VPN 泄露归类为功能性缺陷而非安全漏洞，导致这些报告常在没有外部状态更新或提升修复优先级的情况下被关闭。
• Internal issue tracking 是 Google 的主要开发机制，外部 bug report 更像是一种沟通手段。即便未来的重大版本可能会修复问题，那些被判定超出 bounty program 范围的报告也往往会被关闭。
• Android 对低严重性问题的补丁回移流程基本已停止，这意味着未被定为 High 或 Critical 的漏洞，很可能只有在最新的重大系统版本中才会得到修复。
• GrapheneOS 正积极推进对 Android VPN 实现的全面重构，目标是从根本上解决系统性泄露问题，而不是持续进行零散的、被动式补丁。
• 关于 Google 未能解决这些泄露究竟是组织冷漠还是刻意选择，争论不断。有些人认为关闭一个已记录的 issue 等同于默认接受这种风险。
• 在比较 GrapheneOS 与 Google 的响应方面存在分歧。一部分人认为缺乏回应或进展缓慢不应自动解读为恶意；另一部分人则认为两者在透明度和优先级上的根本差异，本身就是一个有意义的信号。
• 近期围绕 GrapheneOS 的讨论因持续且带有恶意的刷屏和骚扰变得复杂，导致许多合乎技术性的讨论被过度标记。
• 包括对 NAT-T keepalive 机制的研究在内的技术调查表明，所发现的漏洞可能更多与 Wi-Fi 硬件的实现有关，而非蜂窝网络连接。
• VPN 用户当前需要格外谨慎，例如使用支持硬件级路由的路由器，或强制将所有流量通过隧道（tunnel），因为移动数据连接仍容易受到各种绕过类漏洞的影响。
• 虽然许多用户使用 VPN 只是为了绕过地理限制或访问区域定价等简单目的，但事实是现有 Android 的 VPN 实现容易出现严重泄露，而平台维护者目前并未将此类问题视为高优先级的安全关切。
这场讨论反映出对 Google 在隐私保护功能上投入程度的深刻怀疑，人们将其官僚且通常不透明的内部流程，与像 GrapheneOS 这样以社区为导向、透明的做法进行了对比。尽管参与者普遍认同 Android 当前的 VPN 实现存在重大全局性缺陷，但在这些漏洞是技术债务与优先级模型转变的产物，还是对用户隐私的漠视上，意见分歧甚大。此次对话突显了寻求更强安全性的高级用户需求，与大型软件平台倾向于优先保证大众市场稳定性而非小众保护措施的标准操作程序之间日益紧张的矛盾。 • Google classifies VPN leaks as valid functional bugs rather than security vulnerabilities, which results in these reports being closed without external status updates or prioritization for fixes.
• Internal issue tracking is the primary mechanism for Google's development, and external bug reports serve mainly as communication tools. Reports deemed outside the scope of the bounty program are frequently closed, regardless of whether a fix is planned for future major releases.
• Android's patch backporting process for lower-severity issues has been largely discontinued, meaning that if a flaw is not classified as High or Critical, it will likely only be addressed in the newest major version of the operating system.
• GrapheneOS is actively working to overhaul the Android VPN implementation, aiming to resolve systemic leak issues rather than applying continuous, reactive patches.
• Debate persists regarding whether Google's failure to address these leaks is a result of organizational indifference or a deliberate choice, with some arguing that closing a documented issue serves as a tacit admission of acceptable risk.
• Disagreement exists over comparing the responsiveness of GrapheneOS and Google. Some argue that a lack of response or slow progress should not automatically be interpreted as malice, while others contend that the inherent difference in transparency and priorities between the two entities makes their handling of the issue a meaningful signal.
• Recent discourse surrounding GrapheneOS has been complicated by persistent, malicious brigading and harassment, leading to excessive flagging of legitimate technical discussions.
• Technical investigations, including research on NAT-T keepalive mechanisms, suggest that the identified vulnerabilities may be tied specifically to Wi-Fi hardware implementation, rather than cellular connections.
• The current landscape for VPN users necessitates cautious behavior, such as using hardware-level routing or routers that force all traffic through a tunnel, as mobile data connections remain prone to different classes of bypass vulnerabilities.
• While many users utilize VPNs for simple tasks like bypassing geo-restrictions or accessing regional pricing, the technical reality remains that existing Android VPN implementations are prone to significant leaks that are not currently treated as high-priority security concerns by the platform maintainer.
The discussion reflects deep-seated skepticism toward Google's commitment to privacy-preserving features, contrasting its bureaucratic, often opaque, internal processes with the community-driven, transparent approach of projects like GrapheneOS. While participants broadly agree that Android's current VPN implementation has significant, systemic flaws, they diverge sharply on whether these vulnerabilities are the result of technical debt and shifting priority models or a more cynical disregard for user privacy. The conversation underscores a growing tension between the requirements of power users seeking hardened security and the standard operating procedures of large-scale software platforms that prioritize mass-market stability over niche protective measures.