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 socket 被銷毀時，系統可能希望優雅地終止會話。為了促進這一點，Android 引入了一個 API，允許應用程式註冊特定的 UDP 負載（payloads）以便在 socket 銷毀時發送。

根據技術分析，該漏洞透過以下機制顯現：

  1. 任意負載註冊：具有標準 INTERNET 和 ACCESS_NETWORK_STATE 權限的應用程式可以在 system_server 程序中註冊任意 UDP 負載。
  2. 特權傳輸：當應用程式的 UDP socket 隨後被銷毀時，system_server——一個具有高度特權的程序——會傳輸儲存的負載。
  3. 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 裝置開發的隱私中心型作業系統，做出了快速回應。在版本 2026050400 中，該專案透過完全禁用 registerQuicConnectionClosePayload 優化功能來中和化了攻擊向量。

除了此特定修復之外，該更新也整合了 2026 年 5 月的 Android 安全修補程式層級，更新了多個分支的 Linux kernel，以及實施了對 Dynamic Code Loading 的進一步限制。

社群觀點與技術批判

此洩漏問題的揭露引發了技術社群的重大辯論，特別是關於 Google 拒絕修補它的問題。一些觀察者建議，這種「洩漏」可能並非偶然，一位評論者指出：

"Just like manifest v3, it's not in their best interests to disallow snooping。 It hurts their business model。"

從更深層的技術角度來看，一些分析師認為，該漏洞不僅僅是一個簡單的洩漏，更代表了 Android sandbox 的失敗。一位社群成員指出，該漏洞涉及一個程序在沒有適當權限檢查的情況下，設定一個任意位元組陣列供 OS 在其代表下發送，這在他們看來相當於「權限提升」與「應用程式 sandbox 逃逸」。

原生 Android 使用者的用法建議

對於無法切換到 GrapheneOS 但希望在原生 Android 上減輕此風險的使用者，研究員建議透過 Android Debug Bridge (ADB) 進行手動解決方案。使用者可以禁用 close_quic_connection DeviceConfig flag。然而，這是一個臨時措施，需要開發者權限，且可能會被未來的系統更新覆蓋。

這起事件有力地地提醒了「標準」安全與「強化」安全之間的差距。雖然原生 Android 提供了一套廣泛的工具，但 GrapheneOSOS 繼續證明了為什麼對於那些其威脅模型要求絕對網路隔離的使用者來說，專門的、安全第一的開發方式是必要的。

Sources