ハクソク

世界を動かす技術を、日本語で。

Pixel 10向けの0クリックエクスプロイトチェーン

6時間前原文(projectzero.google)

概要

  • Google Pixel 9 のゼロクリックからroot権限取得までのエクスプロイトチェーン公開
  • Pixel 10 向けに同様のエクスプロイトチェーンを作成
  • VPUドライバ に重大なカーネル脆弱性発見
  • 脆弱性は 迅速にパッチ適用 され、Androidの対応速度向上を示唆
  • Androidドライバの セキュリティ強化の必要性 を強調

Pixel 9のエクスプロイトチェーンとDolby脆弱性

  • ゼロクリック脆弱性 （Dolby）を利用したPixel 9のroot権限獲得エクスプロイトチェーン
  • 脆弱性は Android全体 に存在し、2026年1月にパッチ適用
  • Pixel 10用のエクスプロイトチェーン作成を目指す動機

Dolby Exploitのアップデート

  • CVE-2025-54957 向けエクスプロイトのバージョンアップ
  • Pixel 9用のライブラリの オフセット をPixel 10用に調整
  • Pixel 10では RET PAC 導入により__stack_chk_failの上書き不可
  • dap_cpdp_init を上書き対象に選定し、機能的な問題を回避
  • このエクスプロイトは 未パッチ（SPL 2025年12月以前）端末のみ有効

BigWave削除とVPUドライバの追加

  • Pixel 10では BigWaveドライバ が非搭載となり、従来の特権昇格リンクは利用不可
  • 新たに /dev/vpu としてVPUドライバがSELinuxコンテキストで確認
  • Chips&Media Wave677DV 用ドライバで、BigWaveドライバと同じ開発者チームが担当
  • Jann Horn と協力し、VPUドライバを2時間監査し、深刻な脆弱性を発見

VPUドライバのカーネル脆弱性

  • vpu_mmap 関数の設計ミスによる物理メモリの無制限マッピング
  • remap_pfn_range 呼び出し時、VMAサイズの上限チェックがなく、任意の物理メモリ範囲をユーザー空間にマッピング可能
  • カーネルイメージ（.text, .data領域）へのアクセス・改変が容易
  • Pixel端末ではカーネル物理アドレスが固定のため、オフセット計算が簡便
  • 任意のカーネル関数上書き によるコード実行、または任意のプリミティブ獲得が可能
  • 5行のコード でカーネル任意読み書き達成、1日未満でフルエクスプロイト完成

パッチ適用プロセスと評価

  • 2025年11月24日 にバグ報告、Android VRPでHigh評価
  • Pixel 9のBigWaveバグはModerate評価だったが、今回の対応は前進
  • 71日後 （2026年2月Pixelセキュリティ速報）にパッチ公開
  • Androidドライババグの初回報告から90日以内でのパッチは初

結論と今後の課題

  • Project Zero の目標は個別バグ修正を超えたシステム的なセキュリティ改善
  • VPU脆弱性対応はAndroidのトリアージ体制進化を示す
  • 重大な脆弱性の 迅速なパッチ はユーザー保護に寄与
  • 一方で、 ドライバコードの堅牢化 とセキュリティ意識向上が今後も不可欠
  • BigWave報告後もVPUで即発見できる浅いバグが残存
  • ベンダーの積極的なコード監査・開発プロセス改善 の継続的推進が重要
  • セキュリティレポートは複雑な問題を明らかにするが、 製品出荷前の脆弱性排除 と セキュリティ重視の開発文化 が不可欠

Hackerたちの意見

これは素晴らしいバグレポートだね！俺はカーネルの専門家じゃないけど、10年以上前にちょっと読んだことがあるんだ。それでも、内容を追って何が起こっているのか理解できたよ。これが本当にひどいバグだったから、他にどんな危険が潜んでいるのか考えると怖くなる。しかも、見つけるのにそんなに手間がかからなかったしね。あと、最近のセキュリティ問題はAIを使って発生しているのが多いってのも注目すべき点だね。このレポートを見て思ったことは二つ。1. 専門知識はやっぱりめちゃくちゃ価値がある、ニッチな分野ほど価値が高い。2. まだAIが支配していないニッチな分野がたくさんあるってこと。

うーん… 誰か俺の考えをダブルチェックしてほしい。gpt 5.5 xhighにこのプロンプトをそのまま投稿したんだ: does this look right to you? don't do any searches or check memory, just think through first principles static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; } そしたら、ウェブ検索なしで問題を正しく特定してくれたんだ。もっと包括的なことを試してみたいな、例えば特定の関数だけじゃなくてコードベース全体をプロンプトに突っ込むとか。でも、セキュリティの脆弱性を見つける能力は確かにあるみたいだね。だから、そもそもこれがどうやって漏れたのか気になる。おもちゃみたいな例を使ってるけど、もっと学びたいな！

└

こういうひどいコードを書いた人や、それをリリースした会社に対して、何の罰もないのがいつもの問題だよね。もしこのコードを書いた人が一生刑務所に入れられるとか、リスクにさらされたユーザー1人につき100万ドルの罰金を会社に科せられる（それだとGoogleは1兆〜10兆ドルの罰金になって、倒産するかも）ってなったら、状況は全然違ってたと思う。

└

ちょっとしたエピソードだけど、fragnesia.cとその後の提案されたパッチを提供したんだ。新しい脆弱性を発見することはできなかったけど、同じ根本的なバグを利用する新しい方法を2つ見つけられたと思う。たったのClaudeのサブスクリプションを持ってるバカな俺にしては、結構すごいことだよ。

└

どうやってそれがウェブを検索してないってわかったの？

└

コードをインターネット接続なしでClaude Opus 4.7に貼り付けて、関数が何をするのか教えてって頼んだら、説明してくれて、バグも指摘してくれたよ。バグを探してくれって言わなかったのにね。> 観察と潜在的な問題 いくつか注意すべきことがあるよ：1. マッピングサイズに対する境界チェックがない。ユーザースペースがvm_end - vm_startとvm->vm_pgoffを制御してる。ここでvm_pgoffは完全に無視されてて、サイズは盲目的に信頼されてる。例えば、VPUのレジスタブロックが64KBだけど、ユーザースペースが1MBのマッピングを要求したら、ドライバはcore->paddrから始まる物理アドレス空間の1MBを喜んでマッピングする。隣接する物理アドレスにあるハードウェアを露出させる可能性があるんだ。防御的なチェックはこうだね：--- 70日間のリリースサイクルでは、オープンソースプロジェクトのすべてのPRをボットがスキャンできるようになったら、広範なエクスプロイトの使用を止めるには速すぎないだろう。

└

それはあまり公平なテストじゃないよね。モデルをかなり引っ張ってるし、プロンプトにバグを見つけるって具体的に書いてなくても。要は、今のモデルが神話と同じくらい良いって主張したスレッドでみんなが言ってたのと同じ反論だよ。

「これは特筆すべき速さだね。俺が報告したAndroidドライバのバグが、ベンダーが脆弱性を初めて知ってから90日以内にパッチが当てられたのは初めてだから。」これを聞いてGoogleに対してちょっと安心したけど、Androidの他の部分にはちょっと怖さも感じる。Appleの対応時間はどうなんだろう？

└

前にAppleにセキュリティバグを報告したことがある。数年前のことだけど、パッチが出るまでに約6ヶ月かかったのを覚えてる（信頼性の高いPOCを得るために何度かやり取りがあった）。100%再現可能なPOCを提出してからは2ヶ月くらいだったかな。

└

Androidのベンダーは、長い間アップデートに関して悪名高いよね。その理由の一部は、すべての電話会社が自分たちを他と差別化したいからで、デフォルトのAndroid UIをフォークして、ブランド特有の機能を持つサイケデリックなUIを提供したいからなんだ。でも、それってストックAndroidのアップデートが出たときに、移行するのがすごく大変になるってこと。

└

現在、Androidデバイスの42%がパッチ未適用ってことを考えると、彼らが研究を公開して全てを脆弱にするっていうのは興味深い決定だね。[1] https://gs.statcounter.com/android-version-market-share [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...

└

ブランド名のあるAndroidデバイスでは、OSのセキュリティアップデートが受けられることが期待できるよ。ファーストパーティのベンダーが自分たちでこれを構築してプッシュできるからね。ドライバーやファームウェアのセキュリティアップデートは、場合によるかな。これらはしばしば上流のベンダーから来なきゃいけなくて、そのベンダーが問題を修正する気があるかどうかは分からない。小さいブランドは、予算向けのAndroidデバイスを出して、全くアップデートしないことが多いよ。

ちょっと関連する話だけど、最近公開されるエクスプロイトの数が増えてる気がする。AIがセキュリティツール（攻撃や防御）として話題になってるから、ニュースに出ることが多くなっただけなのかな？毎日のように新しい情報が出てる気がする - Linux、Windows、モバイル、みんなが使ってる様々な一般的なツール、リストは続くね。

└

OSSのセキュリティバグを管理している人たちからの報告によると、報告の数が大幅に増えているらしい。最初は質が低くてほとんどがデタラメだったけど、今はもっと正当なものが増えてきているみたい。

└

最近、広く使われているツールのベンダーにいくつか非常に深刻な問題を報告したんだけど、認められるのがいつも以上に難しかった。対応しているチームが忙しすぎるって聞いたよ。

└

https://lwn.net/Articles/1065620/

└

AIは研究者がコードベースをうまくナビゲートするのを助けていると思うけど、必ずしもAIがうまく悪用しているわけではないよね。

└

これは完全に推測だけど、私はセキュリティ研究者じゃないから、AIが低品質の悪用可能な攻撃面を増やしている一方で、セキュリティ研究者にはその作業を加速させる役割を果たしているんじゃないかと思う。つまり、うまく使えば素晴らしいし、下手に使えば最悪ってことだね。

└

両方の要素があると思う（新しいものを見つけるし、ニュースが盛り上がる）、それに加えて、もっと多くの人が何かを見つけようとしているっていうのもあるね。著者たちはすでにこれをできていたかもしれないけど、役立つ作業を得て結果を検証するにはそれなりの理解が必要だからね。でも、新しいおもちゃやFOMOの要素があって、他のことをしていた時間をもっとこの作業に費やすようになってる。前のレポートに触発されたって言ってる人も結構見かけるし、「モデルがそれを指し示した」っていうのがあって、今バグを見逃したらFOMOを感じるっていうのもあるよね。

└

先週末にこれについて分析したんだけど、2024年には毎日約100件のCVEが公開されてたよ。4月には約200件に達した。2023年から遡ると、公開されたCVEの倍増間隔は約4年から4年半だった。それ以降は約2年だね。確実に急激な増加があったよ。

└

第1部の行間を読むと、問題のコードはAI機能によって導入されていて、エクスプロイトは人間によって見つけられたことがわかるよね。https://projectzero.google/2026/01/pixel-0-click-part-1.html つまり、AIの使用がバグを増やして、人間がそれを取り除かなきゃいけないってことだ！

└

今、AIがセキュリティツールとして注目されてるのは確かだね。他の誰かがCVEsの数が増えてるって指摘してたけど、それがなぜかは言ってないよね。この文章にはAIがこのバグを見つけるのを助けたって書いてないし。人間はまだ自分たちでそれができるみたいだね。

Pixel 9のDolbyデコーダーバグについて読んだけど、整数オーバーフローに基づいているんだ。"+"演算子がオーバーフローするのを許可したのは間違いで、Rustのような新しい言語ではこれを修正すべきなんだけど、まだ修正されてないんだよね。

└

セキュリティを本気で考えるかどうかの指標として、ずっとこれを使ってる。少しずつ近づいてはいるけど、まだメモリ安全性が必要かどうかで議論してる世界では、追加のオーバーフローがトップ10のセキュリティ問題だって気づくまでにはまだ時間がかかると思う。これが静かに存在するトップ10のセキュリティ問題なんだろうね。

└

それは、どのISAもああいう風に加算を実装していないからで、毎回チェックすればパフォーマンスは常に向上する可能性があるし、Rustがこの加算重視のマイクロベンチマークでCより20%遅いって愚痴を言う人もいると思う。ただ、Rustのリリースモードではオーバーフローチェックを有効にできるよ。たった2行で設定できる：[profile.release] overflow-checks = true。ISAに加算と減算のトラッピングバージョンがあった方がいいのかも。RISC-Vがそれをしない理由は、その後にチェックするのに数命令余分にかかるだけだからって言ってる。高性能なRISC-Vチップが出たら、overflow-check = trueのパフォーマンス差を見てみるのも面白いかもね。

└

Rustでは、オーバーフローのチェックをするか、ただラップするか（現代のハードウェアはチェックしないとラップするから、そっちの方が安い）をソフトウェアをコンパイルする時に選べるんだ。デフォルトでは、リリースビルド以外ではチェックが入るけど、リリースビルドでもどこでもチェックを入れることも、デバッグでもチェックなしにすることもできる。Rustでは、オーバーフローしない整数型でオーバーフローするのは間違いとされているから、ラップしたいなら、wrapping_addやWrapping型のような明示的なラッピング操作を使うべきだよ。デフォルトの演算子はラップするからね。でも、チェックをオフにしても、間違っても安全だよ。手動でラッピング操作を呼び出すのと同じ感じだね。あのDolbyのオーバーフローコードはちょっと awkward すぎて、チェックがオフでもRustで書くのは想像できないな。でも、実際にはその場にいなかったからな。プロジェクトゼロにある理由は、境界ミスが発生したからで、Rustならそれを防げたはずだよ。

V4L2のハードウェアビデオデコーディングをサポートするための強化が、長い間マージ待ちだったけど、今はメインラインカーネルに入っているみたい。みんなそんなに待ちたくなかったんだろうね。

プロジェクトゼロは、Androidにバグをフロントドアから報告しなきゃいけないし、AndroidのVRPの重大度分類にも対処しなきゃいけないの？ ずっと、彼らはAndroidオフィスに直接行って、バグを訴えることができると思ってたんだけど。

└

もし彼らが「普通」のやり方でやるのが痛いと感じたら、次に直そうとするのはそれだろうね。

うーん。カスタムデバイスノードのためのカーネルからユーザースペースへのマッピングに対して、boundsが提供されることを保証するようなcopy_(to|from)_userみたいなイディオムがないのは意外だな。

Pixel 9のバグ/エクスプロイトのリンクを見たら、こんなのがあったよ。「ここ数年で、メッセージをよりよく検索・理解するためのAI機能がモバイルフォンに追加されてきました。この変更の一つの影響は、0クリック攻撃の表面が増加することです。効率的な分析には、ユーザーがメッセージを開く前にメッセージメディアをデコードする必要があるからです。」これで学んだことはないの？私が頼まない限り、SMSメッセージを読んだり、行動したりしないで！

└

「でも、ユーザーは自分が何をしたいか分からないんだ！私たちは、彼らに提案やおすすめを毎！起きてる！瞬間に押し付けなきゃ！」

└

「速く動いて、物を壊せ」

AIがNSOなどのビジネスにどんな影響を与えたか、証拠はある？彼らを時代遅れにしたの？それとも、今は超パワーアップしてるの？