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

← Research OEMpocalypse Now: Androidの信頼できないアプリからroot化への汎用的なエクスプロイト戦略 Part 1 は、単一の戦略で非特権AndroidアプリからSamsung、Xiaomi、Oppo/OnePlus/Realmeデバイスをroot化するシリーズです。Lukas Maar 2026年8月31日 androidmadbugs Androidでは、すべてのサードパーティアプリはuntrusted_appと呼ばれるサンドボックス化されたコンテキストで実行されます。このコンテキストからroot化する方法を5人の攻撃的セキュリティ研究者に尋ねると、おそらく5つの異なる戦略が得られ、それぞれにトレードオフがあります。ここでは、私が採用した戦略とその理由を、私が全体を通して物差しとして使用する3つの特性と比較して説明します：信頼性、つまり、どの防御策やカスタマイズが有効になっているかに関わらず、ほぼ100％成功すること。移植性、つまり、カーネルバージョン、OEM、チップセット、またはデバイスごとの調整を最小限に抑えて実行できること。普遍性、つまり、できるだけ多くのデバイスをカバーすること。中心的なアイデアは、SamsungやXiaomiのようなオリジナル機器製造業者（OEM）によって書かれたコードのみをターゲットにすることです。具体的には、OEM固有のカーネルドライバにおけるページUse-After-Free（UAF）をターゲットにし、OEMのSELinuxポリシーがそのドライバへのアクセスを要求する場合、OEM固有のサンドボックスエスケープを使用してそのドライバに到達します。要するに、ページUAFは、カーネルがメモリページを解放した後も、そのページへの有効な参照を残してしまうバグであり、サンドボックスエスケープは、低特権プロセスから高特権プロセスへのコードの移動を可能にするバグです。その後、この戦略をメジャーなAndroid OEMごとに3回インスタンス化し、その過程で複数の脆弱性を見つけ、すべてのSamsungフラッグシップデバイス（少なくともGalaxy S23からS26シリーズおよび最近のZシリーズ）、Xiaomiのミッドレンジからフラッグシップデバイスの大部分、および最近のOppo、OnePlus、Realmeのフラッグシップデバイスをカバーするチェーンをもたらしました。図1：ブートローダーロックされたGalaxy S26 UltraでのSamsungチェーンのエンドツーエンド。他の4つのテスト済みデバイスの録画は、「3つのチェーンを一目で」にあります。この最初の投稿では、戦略の背後にある理由を説明し、2つの代替案と比較します。後続の投稿では、これらのチェーンの技術的な詳細を提供します。TL;DR戦略：OEM固有のカーネルドライバにおけるページUAFを悪用します。OEMのSELinuxポリシーがそのドライバを特権ドメインの後ろにゲートしている場合、まずOEM固有のサンドボックスエスケープを介してそれに到達します。関与するすべてのバグは、汎用Linuxまたはチップセットドライバではなく、OEMコード内に存在します。理由：適切なコンテキストから到達したページUAFは、カーネルバージョン、スラブハードニング、KASLR、CFI、および特定の電話モデルにほぼ依存しない安定した物理ページレベルのプリミティブを提供できます。これはまさに、武器化されたチェーンが必要とするものです。カバレッジ：同じ戦略の3回のインスタンス化により、すべてのSamsungフラッグシップデバイス（少なくともGalaxy S23からS26シリーズおよび最近のZシリーズ）、ほとんどのXiaomiミッドレンジからフラッグシップデバイス、および最近のOppo、OnePlus、Realmeフラッグシップをカバーします。概要Androidカーネル攻撃サーフェス汎用Linuxカーネルの脆弱性チップセットドライバuntrusted_appから到達可能OEMpocalypse戦略ステージ1：サンドボックスからの脱出ステージ2：ページUAFトレードオフ3つのチェーンを一目で結論Androidカーネル攻撃サーフェスOEM固有のコードに到達する前に、非特権アプリがカーネル内で実際に何に到達できるか、そして各種類のカーネルバグが武器化されたエクスプロイトに何を提供するかを振り返る価値があります。3つの階層化されたメカニズムにより、リストは短くなります：AndroidのアプリごとのUIDモデルを介した標準的なUnix Discretionary Access Control（DAC）、その上にMandatory Access Control（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として、Exynos/Xclipseモデル（例：一部地域でのベースS26）ではDRMレンダリングノードとして公開されています。これは、アプリがレンダリングのために直接GPUアクセスを必要とするためです。そして、DSPや一部のチップセットのNPUインターフェースなど、あまり一般的でないノードのテールがあり、さらにOEM固有の追加機能がいくつかあります。これらの存在は、OEM自身のSELinuxポリシーが公開することを選択したものに完全に依存します。この列挙は網羅的または権威的であることを意図したものではないことを述べておくべきです。これは私が手元にあるデバイスで見つけたものであり、正確なセットはモデルやAndroidリリース間で変動する可能性があります。そのリストを見ると、エントリは、それらの背後にあるコードを書いた人によって大まかにグループ化されています：アップストリームのLinuxおよびAndroid共通カーネルコード、チップセットドライバ、およびOEM固有のコード。これらのグループを歩く前に、実際に何を最適化しているのかを述べさせてください。私の見解では、理想的な武器化されたuntrusted_appからrootへのエクスプロイトは3つの特性を持っています。第一に、信頼性、つまり、特定のOEMまたはカーネルバージョンが有効にしている防御策やカスタマイズに関わらず、ほぼ100％成功すること。第二に、移植性、つまり、カーネルバージョン、OEM、チップセット、またはデバイスごとの調整を可能な限り少なくして実行できること。第三に、普遍性、つまり、単一のエクスプロイトが可能な限り多くのデバイスをカバーすること。これらをまとめると、「すべてを支配する単一のエクスプロイト」という理想です。実際のエクスプロイトが完全にそれに到達することはまずありませんが、私が候補を測定する基準です。その基準を念頭に置いて、汎用Linuxバグはリストの中で最も普遍的なものであるため、自然な出発点です。汎用Linuxカーネルの脆弱性最初のグループは、すべてのAndroidデバイスが共有するコードです：アップストリームのLinuxカーネルと、その上に構築されたAndroid共通カーネル（ACK）の追加機能です。io_uring、ネットワークスタック、またはメモリ管理コアなどのバグは、OEMやチップセットに依存しないため、まさに魅力的です。単一のエクスプロイトは、原則として、同じカーネルブランチを実行しているSamsung、Pixel、Xiaomiで機能するはずです。IonStackはこの種の作業の良い例であり、私はそれが本当に印象的だと思います：汎用コードの単一のメモリ管理バグが、複数のOEMのデバイス全体でrootまで押し上げられました。これは、適切に選択された汎用バグがどれほど広範囲に及ぶかを示しています。実際には、2つの理由から、その範囲がエンジニアリング作業の大部分を占めています。最初の理由は、バグの典型的な性質です。アクセス可能なコアLinuxコードは何年にもわたる外部監査を受けており、悪用可能なものから得られるプリミティブは通常制約があり、スラブレベルにあります。例えば、特定のオブジェクトタイプのUAF、限定的なアウトオブバウンズ（OOB）書き込み、または勝たなければならないレースウィンドウなどです。それをrootに変換するには、通常、ヒープグルーミング、クロスキャッシュトリック、情報漏洩、およびその他のエクスプロイトテクニックが必要です。これらのすべてがターゲットシステムのシステムに敏感になる可能性があります。2番目の理由は、単一のエクスプロイトが3つの変化の軸すべてに同時に安定していなければならないことです。カーネルバージョンがあります。