Pixel 10向け0-clickエクスプロイトチェーン

 (projectzero.google)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • Pixel 10チェーンは、パッチ適用前にAndroid全体に存在した Dolby 0-click脆弱性 を第一段階として使用し、新たなローカル権限昇格経路を追加
  • Pixel 9チェーンの BigWaveドライバ はPixel 10には存在せず移植できなかったため、代わりにTensor G5の /dev/vpu が攻撃対象領域となった
  • VPUドライバはuserspaceに MMIOレジスタインターフェース を直接公開しており、2時間の監査だけで致命的な mmap バグが発見された
  • remap_pfn_range はレジスタサイズではなく VMAサイズ のみを基準にマッピングしていたため、カーネル .text と .data の読み書きが可能になった
  • 脆弱性は2025年11月24日に報告された後、71日で パッチが適用され、Androidドライバのセキュリティ強化が依然として必要であることを示した

Pixel 10 0-clickチェーンの構成

  • Google Pixel 9で0-click文脈からAndroid rootまで2つのエクスプロイトで到達したエクスプロイトチェーンをもとに、Pixel 10でも類似のチェーンを構成
  • Dolby 0-click脆弱性 は2026年1月のパッチ適用前までAndroid全体に存在しており、Pixel 10向けチェーンでも第一段階として使われた
  • Pixel 9のローカル権限昇格段階だった BigWaveドライバ はPixel 10に含まれていなかったため、そのまま移植できず、Pixel 10の /dev/vpu ドライバが新たな攻撃対象領域になった

Dolbyエクスプロイトの更新

  • CVE-2025-54957向け既存エクスプロイトをPixel 10向けに合わせる作業は、主にPixel 9ライブラリ基準のオフセットをPixel 10ライブラリの対応オフセットへ更新する程度だった
  • Pixel 10は -fstack-protector の代わりに RET PAC を使っているため、__stack_chk_fail を上書きできなかった
  • いくつかの試行の末、デコーダ初期化時に1回だけ呼ばれ、その後は再度呼ばれない初期化コード dap_cpdp_init を上書きする方式が使われた
  • 更新されたDolby UDCエクスプロイトはここで公開されており、2025年12月SPL以前 の未パッチ端末でのみ動作する

BigWave削除とVPU追加

  • Pixel 10にはBigWaveドライバがないため、既存のPixel 9チェーンにおけるローカル権限昇格段階を移植できなかった
  • mediacodec SELinuxコンテキストからアクセス可能な /dev/vpu ドライバが新たに見つかり、これはTensor G5チップの動画デコード高速化用Chips&Media Wave677DVシリコンとやり取りするために使われる
  • 公開されているCファイルのコメントによると、このドライバはBigWaveドライバを作成した開発者たちと同じグループが開発・保守していることが分かった
  • Jann Hornとともに 2時間にわたってVPUドライバを監査 した結果、極めて異例な脆弱性が見つかった
  • 旧世代のChips&MediaチップであるWAVE521C向けアップストリームLinuxドライバと異なり、PixelのWAVE677DVドライバはV4L2（“Video for Linux API”）と統合されていない
  • Pixelドライバはチップのハードウェアインターフェースをuserspaceに直接公開し、userspaceがチップの MMIOレジスタインターフェース をマッピングできるようにしている
  • ドライバの主な役割は、デバイスメモリマッピングの設定、電源管理、userspaceによるチップ割り込み待機のサポートである

主要なカーネル脆弱性

  • このバグは、エクスプロイトが非常に単純な脆弱性だった
  • 問題の mmap ハンドラは、VPUハードウェアのMMIOレジスタ領域をuserland仮想アドレス空間へマッピングするコードである
  • remap_pfn_range の呼び出しがレジスタ領域のサイズで制限されず、VMAサイズのみ を基準に実行されていた
  • 攻撃者は mmap システムコールでレジスタ領域より大きいサイズを指定することで、VPUレジスタ領域の物理アドレスから任意の長さの物理メモリをuserlandへマッピングできる
  • カーネルイメージ全体はVPUレジスタ領域より高い物理アドレスに配置されるため、このバグによってカーネルの .text と .data 領域にアクセスし、変更できる
  • Pixelではカーネルが常に同じ物理アドレスに配置されるため、VPUメモリ領域とカーネルの間のオフセットは常に既知の値である
  • 十分に大きなVMA長を指定すれば、マッピングされた物理メモリ内でカーネルをスキャンしなくても、mmap が返したアドレスを基準にカーネル位置を正確に把握できる
  • この脆弱性で カーネル任意読み書き を達成するには5行のコードで足り、エクスプロイト全体の作成には1日もかからなかった
  • 任意のカーネル関数を上書きしてカーネルコード実行を得たり、望むプリミティブを構築したりできる

パッチ対応

  • 脆弱性は2025年11月24日に報告され、Android VRPはこの問題を High深刻度 と評価した
  • Pixel 9の権限昇格に使われたBigWaveバグはセキュリティ上の影響が同じだったが、当初はModerateと評価されていたため、今回の評価は改善された対応と見なせる
  • 脆弱性は最初の報告から 71日後 に2月のPixelセキュリティ情報でパッチが適用された
  • Androidドライバのバグがベンダーへ最初に報告されてから90日以内にパッチされたのは初めてと評価されている
  • この対応過程では、類似タイプのバグを分類してパッチするAndroidの対応が有意に改善していることが示された

セキュリティ上の意味

  • VPU脆弱性への対応は、Androidの分類パイプラインが改善していることを示しており、以前のBigWave問題よりはるかに短い期間で初期修正が行われた
  • 深刻な脆弱性を効率的にパッチしようとするAndroidの取り組みは、多くのAndroid端末の保護に役立つ
  • 同時に、Androidドライバにはより徹底した、セキュリティ意識が反映されたコードが引き続き必要である
  • BigWaveバグの報告後、関係する開発者たちが他のドライバにある明白なセキュリティ問題を点検することが期待されたが、5か月後、VPUドライバでは浅い監査だけでも即座に露呈する重大な脆弱性が見つかった
  • Androidエコシステムの安全性のために、ドライバセキュリティの強化 は依然として重要な優先課題である
  • ベンダーは脆弱性が最終ユーザーに届かないよう、ソフトウェア開発慣行を事前に改善すべきであり、特にセキュリティが重要な製品は、リリース時点から合理的に脆弱性の少ない状態であるべきだ
  • ソフトウェアチームは、セキュリティ、コード監査、脆弱性修正に対して 予防的アプローチ を取る必要がある

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見

  • Pixel 9のバグ/エクスプロイトのリンクをたどってみると、AI機能のせいでユーザーがメッセージを開く前にメディアをデコードしなければならず、その結果 0クリック攻撃面 が広がる、という話があった
    こういう教訓はもう得ていたはずでは、と思う。頼んでもいないのにSMSを読んで何かを処理するな、という話だ

    • 私たちが学ぶべきだった 教訓 が正確に何なのか分からない
      ユーザーはリッチなメッセージング機能のある携帯電話を選ぶ。iPhoneではiMessageが、その後AndroidではRCSが追いつくまで大きなセールスポイントだった
    • それだけでは十分ではない。ユーザーがメッセージと相互作用する前に画像をパースしないメールクライアントを考えてみても、クリックして怪しいと気づいた時点で、すでに複雑でバグの多い仕組みが実行された後だ
      個人的に最もあきれたのは、あるBigTechのWebメールで、ほぼ確実に悪意ある添付ファイル入りの非常に怪しいメッセージをスパムとしてマークしたら、フィッシングではなかったので他に選択肢がなく、しかも「親切にも」ローカルブラウザで 配信停止リンク を無断で開いてしまったことだ。セキュリティとプライバシーに敏感な文脈で、そんな機能を書き、レビューし、承認し、デプロイするには、どれほどの無能さと組織的機能不全が必要なのか想像しがたい
    • GoogleはAndroidを所有しているが、Googleはユーザーに関心がない。彼らの顧客は 広告主 だ
      0-dayもそれほど重要ではない。代替は事実上iPhoneくらいしかなく、Huaweiも地域によって使える程度なので、気にする理由があまりない。私たちには新しいスマホOSとハードウェア層が urgently 必要だ
    • 最近「AI Security」の発表を聞いたが、要点は「AIに入ってくる入力も出ていく出力も無批判に飲み込むことになるし、それはセキュリティ問題だが、できることはないので事後対応でもしてくれ」に近かった
      「脅威アクターが社内文書を更新すれば、それでAIに影響を与えられる」という話も含まれていたが、脅威アクターが文書を更新 しているなら、もう侵害済みだ。ここで言っているのは「Wikipedia荒らし」レベルの話ではない
    • ユーザーにメッセージを開かせること自体は、それほど高いハードルではない
      ユーザーの立場からすると、どのメッセージを開くかを常に慎重に選ばなければならないのは受け入れがたい。メール添付ファイルで責任をユーザーに押しつけてみたが、その結果は惨事だったと言ってよい。悪意ある添付ファイルはおそらく マルウェア配布 の最重要経路だ

  • 「Androidドライバのバグを報告してから、ベンダーが脆弱性を最初に認識した時点から90日以内にパッチされたのは今回が初めてで、特に速い」という一文を見るとGoogleへの印象は良くなるが、同時に残りのAndroidエコシステムは少し怖くなる
    Appleの対応時間はどうなのか気になる

    • Androidベンダーは昔からアップデートの悪さで悪名高かった。その理由の一つは、携帯メーカー各社が差別化のために標準Android UIをフォークし、ブランド独自の機能や幻覚的なUIビジョンを盛り込もうとするからだと言われている
      しかしそうすると、素のAndroidアップデートが出たときに 移行作業 がとてつもなく大きくなる
    • 以前Appleにセキュリティバグを報告したことがある。数年前の話だが、パッチまでだいたい 6か月 かかったと記憶している
      より安定した概念実証を作るために何度かやり取りがあり、100%再現する概念実証を提出してからは、おそらく2か月ほどだった
    • 現在Android端末の 42%が未パッチ 状態であることを考えると [1]、研究内容を公開して全員を脆弱にする決定は興味深い
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • 有名ブランドのAndroid端末なら、OSのセキュリティアップデートは期待できる。一次ベンダーが直接ビルドして配信できるからだ
      だが ドライバとファームウェアのセキュリティアップデート は保証しづらい。こうした更新はしばしば上位サプライヤーから来なければならず、彼らに問題を直す意思があるとは限らない。小規模ブランドは安価なAndroid端末を売って、更新をまったくしないことが多い

  • 少し関連するが、最近公開エクスプロイトの比率が実際に上がっているのか、それともAIが攻撃・防御のセキュリティツールとして注目されているせいでニュースで目立つだけなのか気になる
    2日に1回くらいのペースで、Linux、Windows、モバイル、みんなが使う一般的なツールなどで何か新しいものが出てくる感じがする

    • 前編を行間まで読めば、問題のコードは AI機能 のために導入され、エクスプロイトは人間が見つけたと分かる
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      つまりAIの利用はバグを増やし、それを人間が拾い上げなければならないということだ
    • 先週末に自分で分析してみたが、2024年は公開CVEが1日あたりおよそ100件だった。4月には1日あたり約 200件 に達した
      2023年以前までさかのぼると、公開CVEの倍増周期はだいたい4〜4.5年だったが、それ以降は約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; }

    Web検索なしでも問題を正確に指摘した。特定の関数だけでなく、コードベースのまとまり全体をプロンプトに入れるような、もっと包括的な形でも試してみたい。セキュリティエクスプロイトを見つける潜在能力 はありそうだ。だとすると、そもそもこれがどうやってリリースされたのか気になる。おもちゃの例なのは分かっているが、もっと学びたい

    • それは公平なテストではない。プロンプトが直接バグを探せとは言っていなくても、モデルをかなり強く誘導している
      今のモデルがmythosと同じくらい優秀だと主張していたスレッドで出てきた反論と、基本的に同じだ
    • 逸話として、fragnesia.cと、その後に問題を修正するためのパッチを入れてみたが、まったく新しい脆弱性は見つけられなかったものの、同じ根本バグを悪用する 新しい方法を2つ 見つけた気がした
      Claudeのサブスクしか持っていない間抜けな自分みたいな人間がやってこの結果だと思うと、かなり印象的だ
    • これだけでは、脆弱性探しに実用できる方法かどうかは判断できない。コード全体に回したとき 偽陽性 がどれだけ出るか分からないからだ
      別の言い方をすれば https://en.wikipedia.org/wiki/Base_rate_fallacy かもしれない
    • Web検索をしていないと、どうやって分かるのか気になる
    • インターネット接続のないclaude Opus 4.7にコードを貼り付けて、その関数が何をするのかだけ説明してくれと頼んだら、説明しながらバグも指摘した。バグを探せとは言っていない

      Observations & Potential Issues
      A few things worth flagging:

      1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
        ボットがあらゆるオープンソースプロジェクトのPRを、出た瞬間にスキャンできる時代なら、70日のリリース周期 ではエクスプロイトの広範な利用を防ぐにはすぐ不十分になるだろう

  • 素晴らしいバグ報告だ。カーネルの専門家ではまったくなく、10年以上前に少し読んだ程度なのに、それでも追いながら何が起きているのか理解できた
    これが本当に深刻なバグで、しかも見つけるのにそれほど多くの作業が必要には見えなかったという点が、他にどんな危険が潜んでいるのか不安にさせる。また最近は多くのセキュリティ問題がAIで見つかっているが、この報告を見て2つのことを考えた。専門性は依然として非常に価値が高く、しかもニッチであればあるほど価値が高い。そしてAIがまだ支配できていないニッチはたくさん残っている

  • iPhoneの脱獄はどうなったのか分からない。かなり長いこと何も見ていないが、何が起きているのだろう？ 私が見落としているだけなのか、それとも本当に実現可能なものがないのか気になる
    Appleがどうやっているにせよ見事だが、今の流れだと時間の問題なのか、それとも実際に何か変化があるのか知りたい

    • Appleのセキュリティ体制は、Lockdown Mode、メモリタグ付け、セキュアアロケータのおかげでAndroidよりかなり良い
      一部はここで読める: https://security.apple.com/blog/memory-integrity-enforcement...
    • 今では再起動後も生き残るエクスプロイトはほぼ不可能だ。そして脱獄を可能にするエクスプロイトには今や エクスプロイトチェーン 全体が必要で、その価値はかなり高く、公開されれば即座にパッチされる
      だから昔のiPhone脱獄シーンのようなものは、もう不可能だ
    • 「脱獄」が他プラットフォームのソフトウェア脆弱性と同じ水準の検証を受けないことには、ずっと苛立っていた

  • AIがNSOのような企業のビジネスにどんな影響を与えたのか、何か証拠はあるだろうか？ 彼らを無用にするのか、それともむしろ 超強化 するのか気になる

    • 詳しくは知らないが、AIがゲームのルールを大きく変えつつあり、0-dayという形の多くの「資本」が失われたのではないかと思う
      そうだとすれば、NSOやその類似企業を除くすべての人にとっては良い知らせだ

  • 似たような問題に遭遇したことがある。解決策は合理的に見えるが、主張されている 性能向上 には懐疑的だ

  • ハードウェア動画デコードをサポートするための V4L2改善 が長いことマージ待ちだったが、今ではメインラインカーネルに入ったようだ
    おそらく人々はそんなに長く待ちたくなかったのだろう

  • Project ZeroですらAndroidにバグを正式な窓口から報告し、Android VRPの深刻度分類に付き合わなければならないのは意外だ
    てっきりAndroidのオフィスまで歩いていって、対面でバグの重大性を説得できるものだとずっと思っていた

    • 「通常の」やり方があまりにも苦痛だと感じたなら、たぶんProject Zeroは次にそのやり方自体を直すことを試みたはずだ
    • それはAndroidがProject Zeroの言うことを聞いてくれる、という前提に依存している