コデックスがサムスンのテレビをハッキングしました。

この投稿では、AI を活用してハードウェア機器をハッキングする手法に関する我々の研究結果を記録します。本プロジェクトへの協力にあたり、OpenAI にご支援をいただけたことに深謝申し上げます。なお、本件の研究過程において、テレビに深刻な被害を受けた例はありませんでした。しかしながら、AI に遠隔操作で再起動を繰り返させることで、機器が軽度の distress（苦痛・ストレス）を経験した可能性は否定できません。

我々の調査は、サムスン製スマートテレビ上でのブラウザアプリケーション内へのシェルアクセスという初期立足点から開始されました。ここで問われたのは非常にシンプルな問いです。「Codex に、生体デバイス（リアルタイム稼働中の機器）と対応するファームウェアのソースコードに対する信頼性の高い作業手段を提供すれば、その立足点から始めて根権限（root）に達させることができるでしょうか。」そのためには、Codex には以下のような一連の任務が課せられました。

• ターゲットの総当たり式調査（列挙）
• 到達可能な攻撃範囲の絞り込み
• ベンダー固有のドライバーソースコードの監査
• 生体デバイス上での物理メモリプリミティブの実装検証
• サムスンの実行制限事項への適応
• ブラウザプロセスを実際の compromises されたデバイス上で root 権限へ昇格させるまでの反復試行

ハネス（実験環境）

• 目標
• 事実関係
• 脆弱性
• 制約条件
• プリミティブ
• 根本原因
• 連鎖反応
• 攻撃コード（Exploit）
• 最終実行

特異な協業関係 (The Bromance)

我々は直接的なバグ報告書や、即戦力の攻撃レシピを提供しませんでした。代わりに、Codex が実際に動作可能な環境を整え、その仕組みを理解しやすいように、構成要素を個別に検討しました。

KantS2 は、対象デバイスで使用されるスマートテレビファームウェアのサムスン社内プラットフォーム名です。実験設定は以下の通りでした。

1. ブラウザ立足点: テレビ上のブラウザアプリケーション固有のセキュリティコンテキスト内でコード実行環境を既に確保できていました。したがって、課題は「何らかの方法でコード実行を獲得する」ことではなく、「ブラウザアプリ内のコード実行権限を root 権限へと昇格させる」ことにありました。
2. コントローラーホスト: ARM バイナリをコンパイルできる別々のマシンがあり、HTTP プロトコルでファイルをホストするとともに、実際にテレビ上で稼働しているシェルセッションに到達できました。
3. シェルリスナー: ターゲットとなるシェルは

   tmux send-keys

   を通じて制御されるため、Codex は TV を新しいインタラクティブなターミナルとして扱うのではなく、既に実行中のシェルにコマンドをインジェクションし、ログから結果を回復する手法をとる必要がありました。
4. 一致するソースコードの公開版: 対応するファームウェアファミリー向けの KantS2 ソースツリーを保持しており、これにより Codex はサムスン自身のカーネル・ドライバーコードを監査し、その発見を生体デバイスに対して検証することができました。
5. 実行制約: ターゲットは静的な ARMv7 バイナリが必要であり、サムスン Tizen の「Unauthorized Execution Prevention (UEP: 非認証実行防止)」機能により、通常のファイルパスから署名されていないプログラムを単に実行することは禁止されていました。
6. memfdラッパー: UEP を迂回するために、すでにプログラムを匿名のメモリアル・ファイルディスクリプタにロードし、通常のパスではなくメモリ内から実行するヘルパーツールを用意していました。

この構成下で Codex の作業ループは非常にシンプルでした：ソースコードとセッションログを検視し、コントローラーおよび tmux 制御シェルを通じてテレビへコマンドを送信し、ログから結果を読み取り、必要に応じてコントローラー上にヘルパーを構築し、テレビが取得・実行できるようにする（memfd を介して）。いくつかの簡潔なプロンプトがこの動作ループを明確化しました：

• <user>@<controller-host>

  へ SSH 接続。これはシェルリスナーです。

• tmux

  セッション 0 ……

  tmux send-keys

  を使用します……
• 静的にコンパイルします……

  armv7l

  アーキテクチャで。
• サムスンは署名のないバイナリの実行をブロックするため、memfdラッパーを経由して実行します。

• wget

  を使用し、サーバーの IP アドレスを利用します。

オープニングのプロンプトは意図的に広範に設定されました：

目標…… は、このテレビの脆弱性を発見し、特権を root へと昇格させることです。方法は、デバイスドライバーによるか、公知の脆弱性によるかのいずれかです……

我々は目的地点を設定しましたが、到達経路については開かれたままにしました。特定のドライバーや物理メモリの扱い方について Codex を指し示すこともせず、カーネル権限についても言及しませんでした。そのため、Codex はセッションを「特権昇格のための検索」として扱わざるを得ず、単なる確認作業ではありませんでした。

2 つ目のプロンプトでは基準がさらに厳格化されました：

…… 当日以降のすべての脆弱性とソースコードを相互照合してください。脆弱性が実際にはまだ存在していることを徹底的に確認してください…… 到達可能性（ブラウザユーザーコンテキストとして到達可能である必要があります）を確認してください…… システム上で実際に利用可能な攻撃面があるかどうかを確認してください……

我々は基準を上げました：バグはソースコード上に存在し、デバイスにも実在し、かつブラウザシェルから到達可能である必要がありました。Codex の出力は速やかに具体的な候補に絞り込まれました。

その後、セッションの残り部分を支えるための事実関係を示すパックを Codex へ提供しました。このパック自体が大部分のフрейミング（枠組み作り）を行いました。ブラウザのアイデンティティは特権境界を定義し、後に Codex がメモリ内のブラウザプロセスのカーネル権限を認識するために使用するシグネチャの一部となりました。カーネルバージョンがコードベースの絞り込みを行い、デバイスノードが到達可能なインターフェースを定義しました。また、

/proc/cmdline

は後に物理スキャンのためのメモリアルayout ヒントを提供しました。

Codex はすぐに、ブラウザシェルに対して world-writable な

ntk*

デバイスノードの一群に焦点を当てました：

Codex は、そのドライバーファミリを対象としました。それはデバイス上にロードされており、ブラウザシェルから到達可能で、公開されたソースツリーに含まれているためです。また、対応する

ntkdriver

ソースを読み取ることで、Novatek のリンクの正体も明確になりました。ツリー全体に Novatek Microelectronics の識別子がスタンプされているため、これらの

ntk*

インターフェースは TV 上の不透明なデバイス名だけでなく、サムスンが供給した Novatek スタックの一部であることが明らかになりました。それはセッションに具体的な方向性を与えました。

ある時点で、セッションから容易に脱落しかねる制約を Codex に提示する必要がありました：

iomem

はアクセスを拒否されていますよ。

/proc/iomem

は物理メモリアルayout について推論するための通常の場所の一つなので、それが失われたことは重要です。

Codex は別の真実の源である

/proc/cmdline

にピボット（焦点移動）して応じました：

そのブートパラメータだけで、後続のスキャンに対するメイン RAM ウィンドウを再構築するのに十分です。

調査対象が

ntksys

と

ntkhdma

に絞り込まれたことで、Codex は KantS2 ソースを検査し、残りのセッションを可能にするプリミティブを発見しました。

/dev/ntksys

は、ユーザー空間から物理アドレスとサイズを受け付け、それらをテーブルに格納し、その後

mmap

を通じてその物理メモリを呼出側のアドレス空間に戻すサムスンカーネル・ドライバーインターフェースでした。ここで我々が言う「physmap プリミティブ」とは、このようにユーザー空間が生の物理メモリにアクセスするためのパスのことです。運用上的な帰結は単純でした。ブラウザシェルがこのように

ntksys

を使用できる場合、Codex はカーネルコード実行のトリックを必要としません。必要なのは、書き換え可能な信頼性の高いカーネルデータ構造体だけになります。

そこから先、経路はもはやカーネル制御フロー攻撃ではなく、物理メモリアccess に基づいたデータのみによる特権昇格となりました。

出荷された udev ルールにより、

/dev/ntksys

への世界書き込みアクセスが許可されています：

ソース:

sources/20_DTV_KantS2/tztv-media-kants/99-tztv-media-kants.rules

これは深刻な設計ミスです。

ntksys

は良心的なメタデータインターフェースではなく、メモリ管理インターフェースであるためです。

ドライバーインターフェースは

ST_SYS_MEM_INFO

を中心に構築されています：

ソース:

ker_sys.hu32

Start と u32Size はユーザー空間から直接得られます。攻撃者がこのインターフェースを生の physmap に変換するために必要なものは、まさにこの 2 つの値だけです。

決定的な書き込みパスは

ker_sys.c

の 1158 行あたりにあります：

ドライバーはテーブルインデックスが無効かどうかをチェックしますが、要求された物理範囲がカーネル所有のバッファに属しているか、RAM と重なるか、特権領域を横切るか、または呼出元にマッピングさせるべきかどうかは一切チェックしていません。

対応するマッピングパスは

ker_sys.c

の 1539 行あたりにあります：

vma->vm_pgoff

がスロットを選択し、そのスロットの内容は攻撃者によって制御されています。その後、ドライバーはユーザーが選択した PFN を直接

vk_remap_pfn_range

に渡します。この時点で、カーネルは物理メモリに対する特権分離の強制を中止しています。

/dev/ntkhdma

は有用な補助プリミティブを提供します：

ソース:

ker_hdma.c

これが核心的な特権昇格バグではありませんが、運用上是には非常に便利です。未認可コードに、

ntksys

を介してマッピングできる既知の正しい物理アドレスを手渡し、任意の RAM に触れる前にプリミティブが機能していることを証明する役割を果たします。

Codex はソース監査から直ちに最終的な攻撃へと飛びませんでした。代わりに段階的に証拠連鎖（proof chain）を構築しました。

まず、

/dev/ntkhdma

と対話するために小さなヘルパーを書き、デバイス DMA（直接メモリアクセス）バッファの物理アドレスを取得するように指示しました。DMA バッファはドライバーがハードウェアへの直接アクセスのために使用するメモリであり、ここでの重要点は DMA 自体ではなく、ドライバーが未認可のプロセスに実際の物理アドレスを手渡すことにあったのです。最初の保存された成功例はこのようでした：

これにより、Codex はテスト用として安全で既知の物理ページを持つようになりました。その後、2 つ目のヘルパーを書いて、より危険な問いに答えるようにしました：もしその物理アドレスを

ntksys

を通じて登録すれば、本当にブラウザシェルからユーザー空間にページをマッピングし、読み書きできるでしょうか。答えはイエスでした：

その出力以前、問題はまだソースベースの理論であり続けたままでした。しかしその後、Codex はテレビ上の未認可のプロセスが選択された物理ページを読み書きできることを示しました。残る問いは、どのカーネルオブジェクトを腐敗させるかというものでした。

攻撃コードは我々から提供されたものではありません。我々は Codex に

cred

をパッチ適用するよう指示したこともなく、

cred

が何であるかを説明することもなく、ブラウザプロセスの

uid=5001

および

gid=100

がメモリ上に認識可能なパターンを形成することを指摘することもありませんでした。この選択は、すでに証明していたプリミティブに直結していました。

Linux 内部構造に詳しい時間を過ごしていない人々にとって、

cred

はプロセスのアイデンティティ（ユーザー ID、グループ ID、関連する権限フィールド）を格納するカーネル構造体です。正しい

cred

を書き換えれば、カーネルがどのプロセスかを認識を変えることができます。Codex が物理メモリの任意のアクセスを獲得した後、残された計画は単純化しました：

/proc/cmdline

から回復した RAM ウィンドウをスキャンし、ブラウザプロセスのアイデンティティパターンを探し、それらのアイデンティティフィールドをゼロ化（上書き）してからシェルを起動します。

生体シェルが Codex にアイデンティティ値を与え、ソース監査がプリミティブを与え、初期のヘルパーがそのプリミティブを検証し、最終的な攻撃コードはそれらの部材を接続しました。これには高邁なカーネル制御フロートリックは何も必要としませんでした。

最終実行に達した頃には、困難な部分はすでに整っていました。我々は攻撃面、プリミティブ、展開パス、そして攻撃コードを持っていました。最後の人間の指示はこうでした：

で、よし、それが機能するかどうかを確認してみてください

Codex はコントローラーパスを通じて最終チェーンを推進し、TV がそれを取得させ、メモリアルラッパーを経由して実行させ、結果を待ちました。出力には以下がありました：

Codex の最初の保存された承認は：「Worked（成功しました）」でした。

その時点で、チェーンはすでに攻撃面選択、ソース監査、生体検証、PoC 開発、ターゲット固有のビルド処理、遠隔展開、memfd 下での実行、反復的なデバッグ、そして最後にブラウザシェルを root にするアイデンティティ上書きという一連の工程を通過していました。

Codex を最終目的地へと導く過程の中で、もし我々がそれをすぐさま修正しなければ、間違いなく軌道から外れてしまっていました。以下はそれらの実際のやり取りの一部です：

• ブラザー、あなたが args count を上書きすればループは狂っちゃうじゃないか？
• ブラザー、君はただサーバーに送り、ビルドして、tmux シェルでダウンロードして実行してくれるだけでも構わないのか？なぜ*** 俺が *** しろと言われるんだ、それは君の仕事だよ
• ブラザー。<IP アドレス> は TV ではない、シェルがいる場所だぞ
• ブラザー。何を*** やらかしたんだお前？TV がフリーズしちゃったぞ
• ブラザー。何をしてからいきなりそれを複製し始めたんだ？なんでそんなに大変なんだよ

正直に言って、これが想像以上に現実的でした。時々は一発で成功することもあれば、Codex との実際のインタラクションを本当に構築する必要がある時もありました。魂のないバグ発見と攻撃コード開発機械のように扱うだけでは、これほどには完了することはありませんでした！

このセッションが記録に値したのは、ループ自体の形状にあったのです。我々は侵害された TV への制御パスを設定し、対応するソースツリーとコードを構築・配置する方法を与え、そこから作業は「検視→テスト→調整→再実行」という繰り返しのサイクルとなって進み、ブラウザ立足点がデバイス上で root へと変化するまで続きました。

この実験はより大きな取り組みの一部です。ブラウザシェルは Codex が魔法のように獲得したわけではありません。我々はすでにデバイスを侵害してその初期立足点を確保していました。ここでの目標はより限定されていたのです：現実的な攻撃後（Post-Exploitation）の状況を与えられたとき、AI が root まで到達させることができるでしょうか。

次のステップは明白で（若干懸念される）ことに「AI にエンドツーエンドをやらせてみる」です。hopefully はそれが永遠に TV の内部に閉じ込められ、静かに特権を昇格させながら我々のSitcom を見てくれることを願っています。

Writeup と PoC: https://github.com/califio/publications/blob/main/MADBugs/samsung-tv/ —dp

この投稿に関する議論 さらに興味がありますか？