[レポート]AI加速型エクスプロイト:DSPコプロセッサー起点によるMTEを有効にしたPixelの侵害 - CODE BLUE 2025 #codeblue_jp #codeblue2025

[レポート]AI加速型エクスプロイト:DSPコプロセッサー起点によるMTEを有効にしたPixelの侵害 - CODE BLUE 2025 #codeblue_jp #codeblue2025

CODE BLUE 2025で行われた「AI加速型エクスプロイト:DSPコプロセッサー起点によるMTEを有効にしたPixelの侵害」というセッションのレポートです。
2025.11.18

こんにちは、臼田です。

みなさん、セキュリティ対策してますか?(挨拶

今回はCODE BLUE 2025で行われた以下のセッションのレポートです。

AI加速型エクスプロイト:DSPコプロセッサー起点によるMTEを有効にしたPixelの侵害

昨年、私たちはPixel 8で使用されているGoogle独自のDSPコプロセッサにおける、既知のものとしては初のセキュリティ脆弱性を発見しました。Googleは今年初めにこの問題を修正しました。このDSPは文書化されておらず、これまで公に分析されたことがなかったため、リバースエンジニアリングとエクスプロイトにおいて大きな課題を提示していました。

プロセッサのエミュレーションの最初の試みは失敗しましたが、私たちは動的インストルメンテーション技術やその他のトリックを使用してその挙動を解明し続けました。この努力を通じて、私たちはPixel 8上のMTEを含むすべての緩和策をバイパスし、完全なカーネルコード実行を達成できる重大なバグを発見しました。

完全なエクスプロイトチェーンを構築するために、私たちはさらに2つの脆弱性を特定し、それらを連鎖させることで、より低い権限のコンテキストからのエクスプロイトを可能にしました。私たちの研究は、これまで不透明だったコンポーネントの深い探求を示し、現代のAndroidハードウェアにおける新たな攻撃面を明らかにします。

Speakers
Bing-Jhong Jheng ビン-ジョン・ジェン
Pan ZhengPeng パン ゼンペン

レポート

  • 背景の紹介から
    • Android Kernelに対する調査
    • いろんなセキュリティ機能がある
      • PAN
      • UAO
      • CFIなどなど
    • Androidのエクスプロイト
      • Universal exploitはどのAndroidでも使える
      • ChipsetやVender、Moderlで粒度が分かれる
        • MailやQualcomm、SamsungやXclipseなど
      • 今回はPixelについて
    • Pixelは独自のドライバがある
  • なぜこれを選んだか?
    • Pixel GXPは2022年公開であまりこれまで報告がないのでチャレンジしてみた
    • ioctlをGXPデバイスでパフォームすることが調査でわかった
    • オープンな許可がない
    • Allow Listを見つけることができる
    • シグネチャがすべてプリインストールされている
    • それを評価できる
  • Pixel GXP概要
    • TPUとGXPの違い
      • CVE-2023-35645が報告されている
  • XPU Attack Surfaces
    • 他のcoprocessorsにはリサーチがある
    • 他の攻撃からアイデアを得られるか考えた
    • CVE-2022-0847(dirty pipe)
    • CVE-2021-28664
    • CVE-2022-36449
    • CVE-2024-32929(Shrinker Page UaF)
      • kernel rewriteができる
  • いくつかバグの根本原因を紹介
    • CSV-2025-36905
      • mapping dirがチェックされていない
      • メモリがread and writeになる
    • 理論上write read-onlyのバグ
    • PoCを書く前に一歩下がってみる
    • write read-onluがGPUにある場合どうやる?
      • cpu_roをGPUにする
      • remapする
      • あるいはcpu_roを用意してOpenCLかioctlをリバースして使う
  • 最初のチャレンジ
    • GXPファームをエミュレートする
    • リバースすることでwrite memory handlerを見つけられる
    • うまく行けばリアルなハードで試せる
    • IDAで確認してリバースする
    • 数日このアプローチをしてうまく行かないことがわかった
    • 多くのものが公式どおりに機能しなかった
    • ファームはシンボルがなくリバースが難しい
    • このアプローチを暫定的にやめた
  • 2回目のチャレンジ
    • アプリケーションをフックする
    • 記録してreplayする
    • google_cameraがこれを使っていることがわかった
    • read writeが許容されている
    • libgxp.soを発見した
    • GXPドライバと対話できる
    • このFunction nameによってよくわかった
    • Fridaを使ってトレースした
    • 全体的なシーケンスとコアロジックを理解できた
    • 完全にすべてをリバースする必要がなくなった
    • 問題のあるドライバコードにアクセスできることがわかった
    • read-only filesを0埋めして書き込みする
  • Bug patch
    • これをGoogle二報告したあと対策された
  • DSP Exploit
    • Write read-only filesはprimitiveで強力な脆弱性
    • DirtyPipeではsyscallにバグがあるがGXPデバイスではオープンにする必要があるので別の問題を発見した
    • android.hardware.camera.providerを使う
      • レポートのときにrestartを強制して実現できるかも
      • untrusted_appからきてPIDがhide
      • ハイジャックできる
    • プロセス
      • libを自信のものに
      • libc++.soをハイジャック
      • cameraproviderをrestart
      • ペイロードに書き込みカーネルモジュールをインストール
      • modprobeを実行
      • selinuxがある
  • このexploit chainをどう利用するか
    • YouTube Kids/Musicなどを利用する
    • 新しいアプリのUIDを探してセットする
      • 最初のapkを取り除いて置き換える
      • restartできれば成功する
      • 最終的にrootも取得できる
  • MTE Android
    • 新しいセキュリティ機能
    • MTEはハードで動く
    • Pixel8で実装されデフォルトではなかった
    • MTEについて多くの調査がされた
    • MTEはアドレススペースの使われていない高いビットをタグする
    • ハードウェアアクセサレートされたもの
    • 十分なコンピュートリソースがある場合有効
    • しかし全て展開するのは課題
    • Google以外にはSamsung/Xiaomi/Huaweiなどは標準では使わないだろう
  • MTE bypass

感想

新しいMTEに対しても研究がされて攻撃されていくので、対策も大変だなあと思いました。Googleがんばえー

この記事をシェアする

FacebookHatena blogX

関連記事