GrapheneOS、Googleが修正しないとしたAndroidのVPN漏えいを修正
(cyberinsider.com)- GrapheneOS は、Android の「Always-On VPN」と「Block connections without VPN」が有効でも実際の IP アドレスが漏えいし得る VPN バイパス脆弱性を、新しいアップデートで修正した
- この脆弱性は Android 16 のネットワーキングスタックにおける QUIC 接続終了 機能に起因しており、一般アプリが標準権限だけで UDP ペイロードを system_server に登録できていた
- アプリの UDP ソケットが破棄されると、特権を持つ system_server が保存されたペイロードを VPN トンネルではなく物理ネットワークインターフェースへ直接送信し、VPN ロック保護を回避していた
- Google はこの問題を「Won’t Fix (Infeasible)」および「NSBC」に分類し、Android セキュリティ勧告の基準を満たさないと判断して従来の立場を維持した
- GrapheneOS は release 2026050400 で「registerQuicConnectionClosePayload optimization」を無効化しており、2026年5月の Android セキュリティパッチ、hardened_malloc の改善、Linux カーネル更新、libpng の CVE-2026-33636 バックポート修正も含まれている
脆弱性の仕組み
- Yusuf の技術分析によると、脆弱な API は、自動付与される INTERNET および ACCESS_NETWORK_STATE 権限しか持たない一般アプリでも、任意の UDP ペイロードを system_server に登録できるようにしていた
- その後アプリの UDP ソケットが破棄されると、Android の特権を持つ system_server プロセスが、保存されたペイロードを VPN トンネルではなくデバイスの物理ネットワークインターフェースへ直接送信する
- system_server は昇格したネットワーク権限で動作し、VPN ルーティング制限の対象外であるため、このパケットは Android の VPN ロック保護を完全に回避する
- セキュリティ研究者 lowlevel/Yusuf は、Proton VPN と Android ロックモードを同時に有効化した Android 16 ベースの Pixel 8 でこの脆弱性を実証した
- そのアプリは、VPN 保護が完全に有効な状態でもデバイスの実際のグローバル IP アドレスをリモートサーバーへ漏えいさせた
原因と Google の対応
- Google は、ソケットが予期せず破棄された際にもアプリケーションが QUIC セッションを正常終了できるようにする機能を導入した
- 実装は任意のペイロードを受け付ける一方で、そのペイロードが正当な QUIC CONNECTION_CLOSE フレームかどうかを検証していなかった
- 実装は元々、アプリケーションが VPN 専用トラフィックに制限されているかどうかも確認していなかった
- 研究者はこの問題を Android セキュリティチームに報告したが、Google はこれを「Won’t Fix (Infeasible)」および「NSBC」（Not Security Bulletin Class）に分類した
- Google は、この問題は Android セキュリティ勧告に含める基準を満たさないと判断した
- 研究者は、標準権限だけでもどんなアプリでも識別可能なネットワーク情報を漏えいできるとして再検討を求めたが、Google は従来の立場を維持し、4月29日の公開を承認した
GrapheneOS の更新と緩和策
- GrapheneOS は、主に Google Pixel デバイス向けに開発されているプライバシー・セキュリティ重視の Android ベース OS であり、より強力なアプリケーションサンドボックス化、エクスプロイト緩和、Google サービス依存の低減を望むユーザー層に利用されている
- GrapheneOS は release 2026050400 でこの最適化を完全に無効化し、VPN 漏えいを防いだ
- Yusuf は、GrapheneOS が 1 週間もかからずに修正版の配布を完了したと述べている
- 最新リリースには、VPN 漏えい修正に加えて 2026年5月の Android セキュリティパッチレベル 全体が含まれている
- アップデートには、複数の hardened_malloc 改善、Android の 6.1・6.6・6.12 ブランチ全体にわたる Linux カーネル更新、libpng の CVE-2026-33636 バックポート修正が含まれている
- 新しい Vanadium ブラウザビルドと拡張された Dynamic Code Loading 制限もあわせて提供される
- 標準の Android ユーザーは、ADB 経由で close_quic_connection DeviceConfig フラグを無効化することで、一時的に問題を緩和できる
- この回避策には開発者アクセス権が必要となる
- Google が今後のアップデートでこの機能フラグを削除した場合、この緩和策を継続して利用できない可能性がある
1件のコメント
Hacker Newsの意見
system_serverが高いネットワーク権限で動作し、VPNルーティング制限の対象外になるなら、AndroidではVPNは実質的にVPNではないのでは、と思うこのバグとは別に、他のロックされたOSも同じように動くのか気になる
Mullvadなどもかなり前にこの問題を扱っていた
人々が同じ綴りの単語を見て文脈の違いを見抜けず、人間的な信頼をコンピュータの信頼モデルへ誤って拡張してしまうことが心配だ
任意の宛先へトラフィックを直接送れる脆弱性や抜け穴があったのかはよく分からない
system_serverや他の回避経路を直すのがどれほど難しいのか気になるManifest V3と同じで、のぞき見を防ぐことはGoogleの利益に合わない
そうした制限はビジネスモデルに損害を与える
この問題が深刻な技術的理由は、漏えいが**特権プロセスである
system_server**から発生している点だAndroidの独自ロックダウンモードは、いかなるトラフィックもVPNを迂回しないと明示的に約束している。システム自体が物理インターフェースへパケットを送るなら、その約束はユーザー空間ではなくカーネルレベルで破られているので、「セキュリティ告知級ではない」と言うのは難しい
Googleが4月29日に公開を許可したのなら、その時点でもエンバーゴを守り、修正配布を5月まで遅らせたのは驚きだ
なぜすぐ公開しなかったのか分からない
良くも悪くもGrapheneOSはGoogleが支配するAndroidに依存している
悪いビジネス上の理由があるのは分かるが、VPN漏えいをセキュリティ問題ではないと分類しながらプライドを保てるのか分からない
もともとVPNは、別のネットワーク経由でプライベートネットワークや業務ネットワークへアクセスするためのもので、拠点間接続や自宅からオフィスへ接続する用途だった。後になって一種のセキュリティツールのようになった
VPNコードを「携帯電話が5Gでオフィスのプリンターにアクセスできればよい」程度に見るなら、QUIC接続が正しく閉じられない小さなバグかもしれない。逆に「このWireGuardトンネルが何があっても自分の身元を守るべきだ」あるいは「インターネットを行き来したすべてのトラフィックの正確なコピーであるべきだ」と見るなら大問題だ
Android VPNや、事実上ほとんどあらゆるVPNも、プライバシー保護・セキュリティ手段として設計されたものではないと思う。特に端末上でコードを実行できるアプリに対してはなおさらで、端末自体もモデムチップ内部を含め、さまざまなネットワーク相互作用を行う
Googleがバグをクローズしたのは失策だったが、バグバウンティプログラムでセキュリティバグと見なさない理由は理解できる
Googleは広告会社であり攻撃請負業者でもあるので、VPN利用者がパケットを漏らすことは両方の理由で利益になる
Metaがエンドツーエンド暗号化を削除するのにも似ている
「いや、私たちは君が話し、行動することをすべて見たいのだ」に近い
GrapheneOSのスマホを手に入れる良い方法が知りたい
GrapheneOSを試してみたかったが、実際にPixelを買うのはためらわれる。中古でも「a」シリーズですら普通は300ドルを超え、数世代前まで下がる必要がある。ブートローダーのロック解除が可能かも問題だ。新しいPixel 10aに449ドル出すのはまだ厳しい
参考までに、Google Fiの発売時にPixel 10aを約300ドルで買った
Pixel 9aがほぼ同じ端末で、まだ新品で販売されている
通信キャリアの店舗ではなく一般の販売店やGoogle Storeで新品を買う方が確実だ
中古はOEMロック解除処理の問題があるため賭けに近いので、返品ポリシーが良いか確認し、購入前にOEMロック解除へアクセス可能か検証すべきだ
基本的には、ブートローダーのロック解除が確実に可能なPixel 6以降の端末を買えばよい。ただしPixel 6はまもなく最低限のサポートだけになるので、Pixel 7以降を勧める。中古出品の大半はブートローダーのロック解除ができない
つまり、Googleから直接買うか、すでにGrapheneOS/CalyxOS/LineageOSがインストールされたeBayの出品を買うか、販売者が明示的にブートローダーのロック解除が可能だと述べている端末を買うのがよい
個人的には、販売者がすでに言及していない限り、ブートローダー確認を依頼しても無駄だった。ほとんど誰も確認手順を踏もうとせず、答えはたいてい「できない」可能性が高く、質問を誤解して単に「アンロック端末」だと返すこともあり、その手の質問にうんざりしている場合もある
より多くのスマホハードウェアをサポートする作業が進行中で、どのブランドかはしばらく推測の対象だった
GrapheneOSを試そうとして中古のPixel 6を安く買ったが、あまり気に入らなかった
LineageOSのユーザー体験の方がずっと良いと感じる。パッケージマネージャの構造がマトリョーシカのように奇妙だ。標準の「App Store」にはいくつかの基本プログラムしかなく、そのうちの1つがさらに別のパッケージマネージャであるAccrescentだが、アプリ数は依然としてかなり少ないので、また別のパッケージマネージャが必要になる。GrapheneOS側はF-DroidよりObtainiumを好むようだが、これも奇妙な判断に見える
完全なオープンソースのパッケージマネージャをはるかに好むし、GitHubのパッケージを信頼する代わりに、外部でソースからビルドし、可能なら再現可能ビルドにすることには実際の価値がある。GrapheneOSのセキュリティモデルは妙に中央集権的に見える。報告されているプライバシーとセキュリティ上の利点は自分では判断しにくい
なぜ決め打ちでプリインストールされたアプリストアがどうしても必要だとこだわるのか分からない
アプリストアを運営するのはAndroidフォークを維持するのと同じくらい大変で、すでにF-Droid、Play StoreとAurora Store、Obtainiumなど複数の選択肢がある状況で、GrapheneOS開発者が莫大な労力を費やさないことを責めるのは難しい
デフォルト状態にはランチャーと最小限のOSしかなく、ミニマリストにはそれで十分だ
さらに必要なら、ユーザーがどこへ行くか決めればいい。私はこれをユーザーに権限を与えるやり方と呼ぶが、あなたは不便と呼んでいるようだ。そうなら、そのOSはあなたに合っていないのかもしれない
「オープンソース」は基本的にはライセンス用語にすぎない
GrapheneOSの「App Store」は、一般的な利用に必要な最も基本的なアプリを提供するためのものだ。Accrescentがそこで配布されるのは、実際のアプリストアとしてAndroidのセキュリティ基準線に従っているからで、F-DroidやAurora Storeはそうではないからだ
F-Droidのように第三者がアプリをビルドして悪意ある動作を確認する方式には、大きな価値はないと思う。そうした検査は信頼性が低く、回避されたこともある。WireGuardがもはやF-Droidにない理由の1つもそれだ。開発者から直接受け取るほどそのアプリを信頼できないなら、そのアプリは使うべきではない
GrapheneOSのプライバシーとセキュリティ上の利点は、平均的なユーザーにはほとんど見えないように設計されている。たとえばメモリ破損バグを防ぐための強化メモリアロケータやメモリタグ拡張、そしてGoogleが端末全体を制御できないようにしつつGoogleサービスを使える、サンドボックス化されたGoogle Playをインストールできる機能がある
GrapheneOSのApp Storeは、AOSPが必要とする第一党アプリストアの役割を満たすために存在する。また、第一党アプリをOSアップデートとは別に更新し、場合によってはアプリをミラーリングする役割も持つ
Accrescentはプライバシーとセキュリティに重点を置いているためミラーリングされている。現在はアルファ状態でアプリ提出は閉じられているが、まもなく開く予定だ
Google Playは、Google Playを必要とするアプリとの互換性、およびPlay Storeへのアクセスのためにミラーリングされている
GrapheneOSコミュニティがObtainiumを好む理由は、GitHubのような場所から開発者署名済みアプリを取得できるからだ。F-Droidはメインリポジトリのほぼすべてのアプリを、古いビルドインフラと不十分な調整体制で署名しビルドしている
GrapheneOSのセキュリティモデルは、AOSPのセキュリティモデルを継承し、その上に追加の強化を施したものだ
GrapheneOSには優れた技術的実装が多いが、Calyxの方がより単純で、素のAndroidに近い形で処理している部分が多いように見える
GrapheneOSは「VPN漏えい修正」のために
registerQuicConnectionClosePayload最適化を無効化し、サポート対象のPixel端末で攻撃ベクトルを事実上無力化したというつまりGrapheneOSは、最適化を切ることで漏えいを「修正」したわけだ
以前HNではQUICが称賛され、QUICが誰に最も利益をもたらすのかと尋ねるコメントが低評価されたことがあった。QUICの利用は他者の利益には合うかもしれないが、自分にはトレードオフが見合わないのでQUICトラフィックを遮断している
QUICはAndroidのようにGoogleが配布するソフトウェアでデフォルト有効になっている場合があり、場合によっては無効化する方法もない
GrapheneOSが削除したのは、アプリがクラッシュするなどの状況でOSにQUIC接続を自動で閉じてほしいと要求する方法だけだ。サーバー視点では、接続が開いたまま残ってリソースを保持し、アイドルタイムアウト後に終了処理へ進む事態を避けられるので最適化だが、クライアント視点の最適化ではない
GrapheneOSはこれ以外にも約5件のVPN漏えいを修正しており、追加修正も進行中だ。Androidの現在のVPN実装はプロファイル単位のVPNだが、プロファイルがまだ独自のネットワーク名前空間を使っておらず、DNSリゾルバや複数の中央サービスがVPNサポートを正しく扱わなければならないため、漏えいに弱い
今後はVPN構造を改善して、漏えいに非常に強くする計画がある。アプリやアプリ群を仮想マシンで実行するサポートも入る予定で、これはより強い保護を提供できる
QUIC自体は優れたもので、これはプロトコルの機能ではなく、監視OSであるGoogle Androidの機能に近い
しかも最新リリース前のOSで確認したときも、まともに動作していなかった
素のAndroidはスパイウェアでありアドウェアだ
昔ならこういうソフトウェアは悪質と呼ばれて削除されていただろうが、今ではそれがデフォルトになった
ユーザーの99%は気にしないと分かっているので、圧力をかけられる相手はスマホメーカーしかない。この分野で意味のある影響力を持つ誰にも影響を及ぼす力がなく、無力感を覚える