OEMpocalypse: 非特権AndroidアプリからSamsung、Xiaomiなどのデバイスをroot化

OEMpocalypse 降臨: 単一戦略で未特権Androidアプリからroot権限へ

Samsung、Xiaomi、Oppoデバイスで、単一の戦略を用いて未特権アプリからroot権限を取得するシリーズの第1部。

［画像: OEMpocalypse Now］

Androidでは、すべてのサードパーティアプリはuntrusted_appと呼ばれるサンドボックス化されたコンテキストで実行されます。このコンテキストからrootへ移行する方法を5人の攻撃的セキュリティ研究者に尋ねれば、おそらく5つの異なる戦略が得られ、それぞれにトレードオフがあります。ここでは、私が採用した戦略とその理由を、評価基準として用いる3つの特性に基づいて説明します。

1. 信頼性、すなわち、有効になっている防御策やカスタマイズに関わらず、ほぼ100%成功すること。
2. 移植性、すなわち、カーネルバージョン、OEM、チップセット、またはデバイスごとの調整を最小限で実行できること。
3. 普遍性、すなわち、可能な限り多くのデバイスをカバーすること。

中心的なアイデアは、SamsungやXiaomiのようなオリジナル機器製造業者（OEM）が記述したコードのみを標的とすることです。具体的には、OEM固有のカーネルドライバにおけるページUse-After-Free（UAF）を標的とします。これは、OEMのSELinuxポリシーが、そのようなドライバへのアクセスを必要とする場合に、OEM固有のサンドボックスエスケープを使用して到達します。要するに、ページUAFは、カーネルが物理メモリページを解放した後も、そのページへの有効な参照を残してしまうバグであり、サンドボックスエスケープは、低特権プロセスから高特権プロセスへコードを移行させる任意のバグです。私はこの戦略を3回（主要なAndroid OEMごとに1回）具体化し、その過程で複数の脆弱性を発見し、Samsungの全フラッグシップデバイス（少なくともGalaxy S23からS26シリーズ、および最近のZシリーズ）、Xiaomiの中〜ハイエンドデバイスの大部分、そして最近のOppo、OnePlus、Realmeのフラッグシップデバイスをカバーするチェーンを得ました。

図1: ブートローダーロックされたGalaxy S26 UltraでのSamsungチェーンのエンドツーエンド。他の4つのテスト済みデバイスの録画はThe Three Chains at a Glanceにあります。

この最初の投稿では、戦略の背後にある理由を説明し、2つの代替案と比較します。後続の投稿では、これらのチェーンの技術的な詳細を提供します。

TL;DR

• 戦略: OEM固有のカーネルドライバにおけるページUAFを悪用する。OEMのSELinuxポリシーがそのドライバを特権ドメインの後ろに配置している場合は、まずOEM固有のサンドボックスエスケープを介して到達する。関与するすべてのバグは、汎用Linuxやチップセットドライバではなく、OEMコード内に存在する。
• 理由: 適切なコンテキストから到達したページUAFは、カーネルバージョン、スラブハードニング、KASLR、CFI、および特定の電話モデルにほとんど依存しない安定した物理ページレベルのプリミティブを提供できる。これはまさに、武器化されたチェーンが必要とするものである。
• カバレッジ: 同じ戦略の3つの具体化により、すべてのSamsungフラッグシップデバイス（少なくともGalaxy S23〜S26シリーズおよび最近のZシリーズ）、ほとんどのXiaomiの中〜ハイエンドデバイス、および最近のOppo、OnePlus、Realmeのフラッグシップデバイスがカバーされる。

Overview

• Androidカーネルの攻撃対象領域
  • 汎用Linuxカーネルの脆弱性
  • untrusted_appから到達可能なチップセットドライバ
• OEMpocalypse戦略
  • ステージ1: サンドボックスからの脱出
  • ステージ2: ページUAF
  • トレードオフ
• 3つのチェーンの概要
• 結論

Androidカーネルの攻撃対象領域

OEM固有のコードに入る前に、未特権アプリがカーネル内で実際に何に到達できるのか、そして各種類のカーネルバグが武器化されたエクスプロイトに何を提供するのかを振り返る価値があります。

3つの階層化されたメカニズムにより、そのリストは短くなります。AndroidのアプリごとのUIDモデルによる標準的なUnixの任意アクセス制御（DAC）、その上に重ねられた強制アクセス制御（MAC）としてのSELinux、そしてseccompによるシステムコールフィルタリングです。Android上のすべてのサードパーティアプリは、独自のUID、untrusted_app SELinuxドメイン（またはuntrusted_app_32のようなAPIレベルごとのバリアント）、およびseccompフィルタの下で実行されます。DACはファイル所有権とモードビットを通じてアクセスを制御し、SELinuxポリシーはドメインがアクセスできるデバイスノード、ソケット、ファイルシステムパスを制限し、seccompはアプリがシステムコールのサブセットを呼び出すのを防ぎます。これらを組み合わせた結果、カーネルの大部分、特にドライバスタックの大部分は、まずより特権のあるドメインに移行しない限り到達できません。言い換えれば、DAC、SELinux、seccompは、開始できるカーネルの攻撃対象領域を定義します。

これを具体的にするために、現在のフラッグシップライン、例えばSamsung Galaxy S26ファミリーを取り上げ、untrusted_appプロセスからのカーネル攻撃対象領域を列挙してみましょう。これらのデバイスでは、リストはおおよそ以下のようになります。

• seccompを生き残るコアLinuxシステムコールサーフェス、例えばメモリ管理、VFSレイヤー、futexes、タイマー、基本的なネットワーキング、そして/dev/binderを介したBinder。
• グラフィックスやその他のメディアスタックが依存する共有メモリおよびDMAバッファ（DMA-BUF）ヒープノード。
• GPUドライバ。Snapdragonモデル（例: S26 Ultra）では/dev/kgsl-3d0として、一部地域のエクシノス/Xclipseモデル（例: ベースS26）ではDRMレンダリングノードとして公開されています。これは、アプリがレンダリングのために直接GPUアクセスを必要とするためです。
• そして、より一般的ではないノードのテールがあります。例えば、一部のチップセット上のDSPまたはNPUインターフェース、さらにOEM固有の追加機能の数々。これらは、OEM自身のSELinuxポリシーが公開することを選択したかどうかに完全に依存します。

この列挙は網羅的または権威あるものではないことを明記しておくべきです。これは私が手元にあるデバイスで見つけたものであり、正確なセットはモデルやAndroidリリースによって変動する可能性があります。

そのリストを見ると、エントリはそれらの背後にあるコードを書いた人によって大まかにグループ化されます。アップストリームLinuxとAndroid Common Kernelコード、チップセットドライバ、そしてOEM固有のコードです。

これらのグループを説明する前に、実際に何を最適化しているのかを述べさせてください。私の見解では、理想的な武器化されたuntrusted_appからrootへのエクスプロイトは3つの特性を持っています。第一に、信頼性、すなわち、特定のOEMやカーネルバージョンが有効にしている防御策やカスタマイズに関わらず、ほぼ100%成功すること。第二に、移植性、すなわち、カーネルバージョン、OEM、チップセット、またはデバイスごとの調整を可能な限り少なくして実行できること。第三に、普遍性、すなわち、単一のエクスプロイトが可能な限り多くのデバイスをカバーすること。これらをまとめると、「すべてを支配する単一のエクスプロイト」という理想になります。現実のエクスプロイトがこれを完全に達成することはまずありませんが、これが私が候補を測定する基準です。その基準を念頭に置くと、汎用Linuxのバグはリストの中で最も普遍的なものであるため、自然な出発点となります。

汎用Linuxカーネルの脆弱性

最初のグループは、すべてのAndroidデバイスが共有するコードです。アップストリームLinuxカーネルと、その上に重ねられたAndroid Common Kernel（ACK）の追加部分です。例えばio_uring、ネットワークスタック、またはメモリ管理コアにあるようなバグは、OEMやチップセットに依存しないため魅力的です。単一のエクスプロイトは、原理的には、同じカーネルブランチを実行しているSamsung、Pixel、Xiaomiで機能するはずです。IonStackはこの種の作業の良い例であり、私はそれが本当に印象的だと思います。汎用コードの単一のメモリ管理バグが、複数のOEMのデバイス全体でrootまでプッシュされています。これは、適切に選択された汎用バグがどれほど広範囲に影響を及ぼしうるかを示しています。

実際には、その広範囲にわたる影響が、ほとんどのエンジニアリング作業の焦点となっています。その理由は2つあります。最初の理由は、バグの典型的な性質です。アクセス可能なコアLinuxコードは長年の外部監査を受けており、悪用可能なものから得られるプリミティブは通常制約されており、スラブレベルに存在します。例えば、特定オブジェクトタイプのUAF、限定的な範囲外（OOB）書き込み、または勝たなければならない競合ウィンドウなどです。これらをrootに変換するには、通常、ヒープグルーミング、クロスキャッシュトリック、情報漏洩、その他のエクスプロイトテクニックが必要です。これらのすべてが、ターゲットシステムのシステムに敏感である可能性があります。2番目の理由は、単一のエクスプロイトが3つの変化の軸すべてにわたって安定性を維持する必要があることです。カーネルバージョンがあります。OEMは最新デバイスで5.15から6.12まで出荷しています。OEMレイヤーがあります。OEMはカーネルソースに独自のパッチ（例: SamsungのRKPとKDP）を適用し、独自のランタイム構成（例: mem-cgが有効かどうか）を出荷する可能性があります。そして個々のデバイスがあります。同じOEMの同じカーネルブランチ上の2つの電話でも、RAMサイズやコア数などの異なるハードウェアを出荷しており、これはCPUごとのページリストのウォーターマークやCPUごとのスラブキャッシュの数などのアロケータの動作をシフトさせます。各軸は、ターゲットごとの作業に別の次元を追加する可能性があり、完全に武器化されたエクスプロイトは、月次のセキュリティ情報がリリースされるにつれて継続的な注意を必要とする特殊ケースのマトリックスへと徐々に変化していきます。

これらをまとめると、2つの理由は同じ方向を指しています。バグ自体はほぼどこにでも存在しますが、それを信頼性が高く移植可能なエクスプロイトに変換することが作業の集中点です。その状況を念頭に置いて、次のグループを見てみましょう。

untrusted_appから到達可能なチップセットドライバ

2番目のグループは、パフォーマンス上の理由から、GPU（Mali、Adreno KGSL、PowerVR）やデジタル信号プロセッサ（DSP）、ニューラルプロセッシングユニット（NPU）のように、未特権アプリに直接公開されているチップセットコンポーネントのドライバです。これは、過去数年間の公開されているAndroidローカル権限昇格（LPE）作業の、研究論文と実際の攻撃の両方で、大きく目立つシェアを占めている分野です。実例として、Mali GPUのバグが繰り返し発見されており、Qualcomm DSPドライバadsprpcはいくつかのチェーンに登場しています。研究側の例としては、Project ZeroのSeth Jenkins氏がDSPおよびその他の到達可能なドライバについて詳細に記述しており、GitHub Security LabのMan Yue Mo氏もMaliおよびAdreno GPUの悪用に関する一連の投稿をしています。

これらのバグは、実際に作業する上で非常に優れています。ドライバはユーザー空間に代わって物理ページやGPU/DSPページテーブルを管理するため、バグはしばしば、汎用Linuxバグで通常必要とされるヒープグルーミング、クロスキャッシュ作業、またはリークハンティングのほとんどなしに、ページUAFまたは任意の物理マッピングを直接提供します。その理由は構造にあります。GPUやDSPがユーザーデータを操作できるようにするため、ドライバはページをピン留めし、デバイス固有のページテーブルにマッピングし、その後そのマッピングを解除してページを解放する必要があります。そのパス上のライフタイムの誤り、例えば、デバイスマッピングがまだ指している間にページが解放されたり、参照カウントが多すぎたりすると、ほぼ必然的にページレベルのプリミティブが得られます。これは、コアLinuxコードのスラブレベルUAFとは全く異なる出発点です。

プリミティブは、これらのバグのより直接的な側面であることが多いです。単一のバグによって提供されるデバイスカバレッジの広さは別の問題です。それはバグが影響するチップセットに依存し、それは広く変動します。一方では、adsprpcやKGSLのような共有Qualcommコードのバグは、多くのSnapdragon世代にまたがり、フラッグシップ市場の大部分を占めるSnapdragonが搭載されているため、複数のOEMのデバイスに同時に到達できます。他方では、特定のMaliまたはExynos IPブロック、あるいは特定のMediaTekドライバのリビジョンに結びついたバグは、はるかに小さな範囲をカバーします。チップセットパーティションがOEMパーティションと一致しないことも注目に値します。単一のOEMは、そのラインナップ全体で複数のチップセットファミリーを出荷することがよくあります。例えば、Samsungは一部の地域ではExynosフラッグシップを、他の地域ではSnapdragonフラッグシップを販売しています。そのため、単一のチップセットバグがOEMの全ラインナップにマッピングされることはまれであり、その逆も同様です。

これまでに見てきた2つのグループには共通点があります。どちらもuntrusted_appから直接到達可能であり、その攻撃対象領域はすでにかなり体系的にマッピングおよび監査されています。これにより、リストの3番目のグループ、OEM固有のコードが残ります。その大部分はより特権のあるドメインの後ろにあり、その注意は著しく少ないかもしれません。それが何を提供するのか興味があったので、代替案よりも優れているか劣っているかをここで議論するのではなく、それがどのように見えるかを説明しましょう。

OEMpocalypse戦略

OEM固有のコードとは、Samsung、Xiaomi、またはOppoといったOEMが、Androidの上に独自のソフトウェアスタックの一部として出荷するカーネルドライバやユーザー空間サービスを指します。重要なのは、このコードはチップセットではなく、OEMのソフトウェアレイヤー（One UI、HyperOS、ColorOS）に結びついていることです。そのため、同じコンポーネントは、デバイスがSnapdragon、Exynos、Dimensity、またはその他のものを内蔵しているかどうかにかかわらず、そのOEMのラインナップ全体で一般的に存在します。これが私が探していたカバレッジ特性です。つまり、OEMごとに1つのバグで、原則として、影響を受けるコンポーネントを出荷しているすべてのモデルに到達できます。

したがって、戦略は、これらのOEMドライバのいずれかでページUAFを見つけることです。理想的には、これは単一ステージの攻撃です。つまり、ドライバはuntrusted_appから直接到達可能であり、OEMのSELinuxポリシーがそれを強制する場合にのみ、最初のステージに頼ります。

ステージ1: サンドボックスからの脱出

サンドボックスエスケープが存在する根本的な理由は、Androidにおける分離が絶対的ではないことです。アプリ、システムサービス、ネイティブデーモンは独自のUIDとSELinuxドメインに分離されていますが、それらは互いに通信する必要があります。Androidは、Binderコール、インテント、コンテンツプロバイダ、ローカルソケットなど、多くの方法を提供しています。これらのプロセス間通信（IPC）エンドポイントのそれぞれは、低特権の呼び出し元がより高特権の呼び出し先にデータを送信し、呼び出し先が境界を正しく強制することを信頼する場所です。OEMは、AOSPの上に多数の独自のアプリ、サービス、デーモンを追加し、それぞれが独自のこのようなエンドポイントセットを持っています。その結果、これらのOEM IPCハンドラ内の単一のロジックエラー（例えば、呼び出し元チェックの欠落、公開されるべきではないエクスポートされたコンポーネント、または検証されていないファイルパス）は、特権境界を越えるのに十分です。私たちの目標にとって重要なのは、この種のバグは完全にOEMのユーザー空間ロジック内に存在することです。チップセット、カーネルバージョン、または特定の電話モデルに依存しません。なぜなら、同じ欠陥のあるチェックを持つ同じOEMサービスが、そのOEMのソフトウェアレイヤーを実行しているすべてのデバイスで出荷されているからです。

したがって、ステージ1は、必要に応じて、まさにそれです。OEM IPCエンドポイントのロジックフローの欠陥を使用して、untrusted_appからOEM所有のプロセス（例えば、システムアプリ、プラットフォーム署名サービス、またはネイティブデーモン）に移動します。このプロセスは、ステージ2で到達したいカーネルドライバを開くことが許可されているSELinuxドメインを持っています。具体的なエスケープについては、OEMごとの投稿で詳しく説明します。短いバージョンでは、混乱した副官プリミティブからターゲットプロセス内の完全なネイティブコード実行まで、ステージ2ドライバのインターフェースを駆動できる限り、何でも機能します。

ステージ2: ページUAF

第2ステージは、現在保持しているドメイン（untrusted_app自体またはステージ1を介して到達したドメイン）から到達可能なOEMカーネルドライバにおけるページUAFです。私が他のバグクラスではなく、特にページUAFを探す理由は、結果として得られるプリミティブが、通常Androidカーネルエクスプロイトをターゲット固有のものにするほとんどの要因から独立しているためです。

具体的には、ページUAFは、カーネルが物理ページを解放して再割り当てした後も、そのページを指し続ける参照を提供します。ドライバによっては、その参照はCPU側のユーザー空間VMA、IOMMUページテーブルエントリのようなデバイス側のマッピング、またはDMAパスに配置されるドライバ保持のstruct pageポインタである可能性があります。いずれにせよ、効果は同じです。解放されたページを、私たちが選択したカーネルメモリ（例えば、ページテーブルページや、任意の読み書きプリミティブに変換できる構造体を含むスラブページ）として再利用するように手配し、その後、古いマッピングを介してそれを読み書きします。重要な点は、このプリミティブが通常の悪用メカニズムへの依存をどれだけ減らすかということです。ページレベルで動作するため、CONFIG_SLAB_BUCKETS、CONFIG_RANDOM_KMALLOC_CACHES、またはCONFIG_SLAB_FREELIST_HARDENEDのようなスラブに焦点を当てたハードニングは、古いマッピングを制約しません。通常、KASLRリークを必要としません。なぜなら、カーネルポインタを逆参照するのではなく、すでに保持しているマッピングを介して読み書きするからです。そして、それはデータのみであるため、CFIのような制御フロー保護はそれを制約しません。最後に、ページアロケータの動作は、カーネルバージョン間で比較的に安定しています。これらのチェーンでは、5.15から6.12まで、同じ再利用およびページフェンシュイコードが変更されずに実行されました。

トレードオフ

最初の制限はカバレッジです。この戦略はクロスOEMであることを諦めているため、SamsungチェーンはXiaomiデバイスでは何も機能せず、3つのOEMをカバーするには3つの独立したチェーンが必要です。そして、1つのOEM内でも、すべてのコンポーネントがすべてのデバイスに搭載されているとは限りません。例えばSamsungは、デバイスがフラッグシップかローエンド/ミドルエンドモデルかによって異なるレベルのソフトウェアスタックを有効にしているため、Galaxy SおよびZシリーズ全体に存在するコンポーネントがAシリーズの電話には存在しない可能性があります。実際には、各チェーンのカバレッジは、OEMが脆弱なコンポーネントを出荷することを選択したデバイスのセットに正確に対応します。

2番目の制限は、武器化された攻撃が追跡しなければならない可動部品の数です。各2ステージチェーンは、少なくとも2つの独立したバグに依存しており、OEM全体では、すべてが同時にパッチされていないままでなければならない一握りの脆弱性があります。いずれかが修正されると、そのチェーンは交換バグを必要とします。セットを維持することは、実際の継続的な作業です。

これらのコストにもかかわらず、トレードオフが私にとって魅力的なのは、その見返りです。OEMが脆弱なコンポーネントを出荷する場合、ハードウェアに関係なく同じコードを出荷するため、デバイスのセット内では、チェーンは信頼性が高く移植可能です。1つのSamsungフラッグシップで機能するチェーンは、デバイスごとの調整マトリックスをはるかに小さくして、残りのデバイスでも機能します。このように構築された3つのチェーンは、現在のAndroidフラッグシップ市場の大部分をカバーします。前述の3つの特性と比較すると、信頼性と移植性は理想に近く、普遍性は「すべてのAndroid」から「1つのOEMからのほとんどのデバイス」にスコープダウンされています。

3つのチェーンの概要

ここでは、3つのチェーンが外部からどのように見えるかを示します。それぞれが、宣言された権限のない通常のAndroidアプリとしてパッケージ化されています。各デモビデオは、まずデバイスのAndroidおよびカーネルバージョンを表示し、次にアプリ自身のコンテキストを表示して、追加の権限なしでuntrusted_appとして実行されていることを示します。その後、アプリはエクスプロイトを実行し、rootシェルにドロップし、同じブロックを再度表示します。

User:            uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
SELinux:         Permissive
Verified boot:   green
Bootloader lock: 1
VBMeta state:    locked
Kernel:          ...
Nodename:        ...
Build:           ...

Verified boot: green、Bootloader lock: 1、VBMeta state: lockedの行は重要です。これらは、デバイスがロックされたブートローダーで、署名済みのストックイメージを実行していることを確認します。

（a） Samsungチェーン、Samsung Galaxy S26。

（b） Xiaomiチェーン、Xiaomi 17。

（c） Oppoファミリーチェーン、Oppo Find X9 Ultra。

（d） Oppoファミリーチェーン、OnePlus Ace 6 Ultra。

図2: ブートローダーロックされたストックデバイスで実行される3つのチェーンのエンドツーエンド。

上記の録画は、Galaxy S26でのSamsungチェーン、Xiaomi 17でのXiaomiチェーン、Oppo Find X9 UltraおよびOnePlus Ace 6 UltraでのOppoファミリーチェーンを示しています。これらはすべて、2026年8月初旬時点で利用可能な最新ファームウェアで実行されています。Galaxy S23は表示されていません。私はそれをroot化された開発デバイスとして使用し、カーネル可視性でSamsungチェーンを構築し、その後、ロックされたS26およびS26 Ultraに結果を盲目的に移植しました。以下の表は、各チェーンをテストしたデバイスをまとめたものです。

結論

この記事では、武器化されたuntrusted_appからrootへのチェーンの基準、すなわち信頼性、移植性、普遍性を設定し、それらの背後にあるカーネルコードの3つのグループ、すなわち汎用Linux、チップセットドライバ、OEMコードを概説しました。汎用Linuxとチップセットドライバのバグは、どちらもよく理解されたルートであり、実質的な強みがあります。3番目のグループはOEM固有のコードであり、OEMpocalypse戦略はそれを探求する私の試みです。OEMカーネルドライバでページUAFを見つけ、OEMのSELinuxポリシーが必要とする場合は、まずOEMサンドボックスエスケープを介してそのドライバに到達します。主要なOEMごとに1回ずつ具体化されたことで、現在のAndroidフラッグシップ市場の大部分をカバーする3つのチェーンが得られました。

防御側の観点から、私の結論は、カーネルコードにページUAFが存在すると、それを緩和するのは本質的に難しいバグクラスであるということです。過去数年間にAndroidカーネルに導入されたハードニング、例えばスラブフリーリストとバケット保護、KASLR、CFI、および選択されたカーネル状態に対するハイパーバイザーベースの整合性は、主にスラブレベルの破損と制御フローハイジャックを対象としています。解放された物理ページへの古いマッピングは、そのほとんどの下に位置しています。それは（通常）リークを必要とせず、制御フローをハイジャックせず、ページアロケータが次に割り当てるものへの読み書きアクセスを提供します。実際には、これは防御を、そもそもバグを持たないことに戻します。つまり、カーネル所有のページをユーザー空間またはデバイスアドレス空間にマッピングするドライバを監査し、そのようなマッピングがページが解放される前にすべて解除されることを確認することです。

このシリーズのカーネルバグはいずれも巧妙なものではありませんでした。それぞれがページライフタイムの誤りであり、ドライバの集中的なレビューで検出された可能性が高く、どのドライバも敵対的な呼び出し元を念頭に置いて書かれたという印象はありませんでした。意図された防御線は、そのようなドライバを到達不能に保つことです。それらを専用のSELinuxドメインでゲートし、信頼できるコンポーネントのみがそれに話しかけられるようにすることです。これは、実際に適用されている場合に有用なレイヤーです。そして、それが適用されている場合でも、それはOEM自身のそのドメインへのユーザー空間IPCサーフェスと同じくらい強力であり、ここでのチェーンは、そこでのロジックバグがそれを越えるのに十分であることを示しています。それは、その背後にあるドライバを到達可能と見なすことの代わりにはなりません。

シリーズはOEMごとのチェーンで続きます。

• パート2: Samsung
• パート3: Xiaomi
• パート4: Oppo、OnePlus、Realme

この作業に興味を持った場合、質問がある場合、または技術的な不正確さに気づいた場合は、lukas.maar@calif.ioまでお気軽にご連絡ください。