埋め込みシステムのセキュリティ向上のためのMMIOモデルの改良
MMIOモデルを強化して組み込みシステムのファズテストを改善する。
― 1 分で読む
目次
組み込みシステムは今や至る所にあるよね。ユーザーの重要な情報を集めて、クリティカルな意思決定を助けてるんだ。だから、そのセキュリティはめっちゃ大事。もし組み込みシステムが脆弱だと、何百万ものユーザーの個人情報や安全が危険にさらされちゃう。組み込みシステムをテストする方法の一つがグレーボックスファジングってやつ。これはファームウェアをシミュレーション環境で動かす方法で、効率的なテストが可能になるんだ。
でも、こういう環境でテストする時に、ファジングツールは実際のハードウェアにアクセスできないから、ファームウェアとこのハードウェアのやり取りを理解して、できるだけ多くのコードをカバーする必要があるんだ。今の多くの方法は、ファームウェアがハードウェアとどうやって通信するかをメモリマップドI/O(MMIO)を使ってモデル化することに焦点を当ててる。
現在のモデルの問題点
今のファームウェアファジングで使われるMMIOのモデルは、ファームウェアが周辺機器からデータをどう読み取るかを正確に説明するのが難しいんだ。これがコードカバレッジのギャップを生んで、バグや脆弱性を特定するのが難しくなる。既存のモデルは、ファームウェアが複数回の読み取りでデータを取得する状況を考慮してないことが多い。この制限は、主に2つの理由で際立ってる。
まず、ほとんどの現在のモデルはシステムの状態を認識してないから、同じMMIOレジスタからの複数の読み取りを区別できない。これが重要なのは、データの塊が異なるルールに従った異なるバイトで構成されてる場合があるから。次に、MMIOの読み取りにモデルが割り当てられると、それがテスト中は固定されちゃう。つまり、モデルはファームウェアがデータをどう処理するかに合わせて適応できないんだ、これはコンテキストによって変わるかもしれないのに。
提案された解決策
こうした問題に対処するために、新しい方法でMMIOモデルを洗練させる提案がされてる。この新しいアプローチは、ファームウェアの動作コンテキストに応じて変化できる適応可能なMMIOモデルを構築するものだ。ファームウェアファジングツールを使ってモデルとテストケースを生成することで動作する。テストが終わった後、ファジングツールは最高のカバレッジを持つテストケースで実行して実行トレースを集めるんだ。
そのトレースが、状態を持っていて適応可能なMMIOモデルの作成に役立つ。ファジングツールとモデルの洗練作業の間で交互に行うプロセスの目的は、ファジングテスト中のカバレッジを向上させることだ。提案された方法は人気のファームウェアを使って評価され、他のケースでの効果を大きく損なうことなくカバレッジの改善が見られた。
組み込みシステムとその重要性
組み込みシステムは、特定の機能やタスクを実行するための専門的なコンピューター装置だ。家庭用機器から産業機械まで、いろんなアプリケーションに使われてる。こうしたシステムが日常生活にますます統合されるにつれて、そのセキュリティが超重要になってくる。組み込みシステムの脆弱性は、大きなプライバシーやセキュリティの侵害につながる可能性があるんだ。
その使用が増えてるから、組み込みシステムの脆弱性を効率的に検出することが重要だ。ファジングはそのために人気のある方法で、ランダムな入力を生成してプログラムをテストして、クラッシュやハングの可能性を探ってる。
グレーボックスファジングの説明
グレーボックスファジングでは、ファジングツールはテスト対象のコードの一部を知ってる。過去の実行からのフィードバックを使って、時間が経つにつれてより良い入力を作るんだ。このフィードバックは、テストされた入力でプログラムのコードがどれだけ実行されたかを測るコードカバレッジから得られることが多い。コードカバレッジが高いほど、新しいバグを見つけるチャンスが増える。
組み込みシステムに適用されると、グレーボックスファジングはエミュレートされた環境を使って、実際のハードウェアなしでファームウェアを実行する。この方法は、新しいファジングツールを簡単に生成できるから、スケーラブルなテストが可能になるから人気なんだ。でも、エミュレーターはファームウェアが意図するハードウェアがどう機能するかを理解してる必要がある。
組み込みシステムのエミュレートにおける課題
ほとんどのエミュレーターの課題は、一つのエミュレーターが組み込みシステムで使われる様々なハードウェア周辺機器について必要な知識をすべて持ってないところ。これが、ファームウェアが意図する周辺機器と対話できるシミュレートされた環境を作るためのエミュレーターのプラグインの開発につながってる。
これらの解決策のほとんどは、ファームウェアが周辺機器とやり取りする一般的な方法であるMMIOのモデル化に焦点を当ててる。MMIOはハードウェアと通信するためにメモリアドレスを使う。一般的に、MMIOレジスタには3つのタイプがある: 制御レジスタ、ステータスレジスタ、データレジスタ。
- 制御レジスタ (CR): ハードウェアの動作を設定するために使う。
- ステータスレジスタ (SR): 周辺機器の現在の状態を報告する。
- データレジスタ (DR): センサーからのデータやアクチュエーターに送信されたコマンドを含む。
各タイプはデータを異なる方法で扱うから、正確にモデル化するのがかなり難しい。この中には基本的なやり取りをうまく扱えるモデルもあるけど、より複雑なケース、特にデータの塊を取得して処理する必要がある場合には苦労してる。
MMIOモデルの重要性
正確なMMIOモデルを持つことは、ファジングツールがファームウェアを効果的にテストするためには欠かせない。モデルがファームウェアが周辺機器とどうやってやり取りするかを正しく説明できなければ、ファジングツールが重要なコードの部分を見逃すかもしれない。これが、脆弱性やバグを特定するチャンスを低くしちゃうんだ。
現在のMMIOモデルは基本的なデータアクセスをうまく処理できるけど、より複雑なデータ構造には対応できてない。例えば、ファームウェアが完全なデータパケットを形成するために複数のバイトを読むことに依存することが多い。モデルがこれを正しく反映しないと、ファジングツールの効果はかなり制限されちゃう。
改善の必要性
現在のMMIOモデルを洗練させて、その精度を向上させる必要がある。既存のモデルは、ファームウェアが周辺機器とやり取りするいくつかの側面を説明できるけど、しばしば適応性がない。こうした硬直性が、特にファームウェアの処理コンテキストが変わるときに脆弱性を検出するのを難しくしちゃう。
状態を持った適応可能なモデルは、ファームウェアの実行中に何が起こるかを正確に反映することで、ファジングテストを向上させる可能性があるんだ。コンテキストを取り入れることで、モデルがデータの塊がどう形成され、処理されるかをより正確に説明できるようになる。
提案された方法のワークフロー
提案された方法は、使用中のMMIOモデルを洗練させて、ファームウェアが周辺機器とどのようにやり取りするかをより良く表現することを目指してる。プロセスは、ファームウェアファジングツールが組み込みシステムのファームウェアをファジングテストするときに初期のMMIOモデルとテストケースを生成するところから始まる。
次に、システムはファームウェアの最高カバレッジ入力での実行に基づいて詳細な実行トレースを生成するテストハーネスをインスツルメントする。これらのトレースは、どの部分のファームウェアが実行されたのか、関連するMMIOの読み取りとともに重要な情報をキャッチするんだ。
その後、トレース情報を使って完全なデータの塊に関連するMMIOの読み取りをグループ化する。このグループ化は、異なるコンテキストでデータがどう処理されるかを正確にキャッチするモデルを作成するために重要だ。
最後に、洗練された状態を持つモデルが、次のファジングテストラウンドでの使用のために登録される。このプロセスを繰り返すことで、方法はファームウェアファジングツールのコードカバレッジを反復的に改善していく。
主要な課題
正確なモデルを構築するには独自の課題がある。状態を持った適応可能なMMIOモデルを開発する際には、データの塊を処理する際の構文と意味論の2つの主要な課題を考慮する必要がある。
データ塊の構文
まず、データがファームウェア内で構造化されている方法の構文を正確に反映しなきゃいけない。モデルは、同じMMIOレジスタからの個々の読み取り間の依存関係を考慮する必要がある。つまり、データの塊の異なるバイトが異なるルールに従う可能性があることをモデル化するってわけ。
モデル構築プロセス中に読み取りを効果的にグループ化することは、この目標を達成するために重要なんだ。システムは、読み取りがどのように関係していて完全なデータの塊を形成するのにどう寄与するかを反映するようにグループ化する必要がある。
データ塊の意味論
次に、モデルはデータの意味を考慮する必要がある。データの塊が何を意味するかの解釈は、コンテキストによって変わるかもしれない。この動的な処理を管理するために、メソッドは実行中に異なるコンテキストに基づいてシンプルなモデルを生成し、それらを一つの適応可能なモデルにマージする。
この問題にこうしたアプローチを取ることで、ファジングテスト中に組み込みファームウェアのコードをより多くカバーして、脆弱性やバグの特定をより良くすることが目標なんだ。
評価
新しい方法は、既存のファームウェアファジングツールのコードカバレッジを改善する効果を確認するために実装され評価されている。初期の評価では、この方法は期待以上の結果を示して、いくつかのテストされたファームウェアケースでコードカバレッジが大幅に向上したんだ。
例えば、いくつかのケースでは新しい方法がカバレッジを最大160%改善できた。これは、他のテストされたファームウェアのバージョンでのカバレッジを大幅に減少させることなく達成された。
結論
組み込みシステムが社会にますます広まるにつれて、そのセキュリティを確保することが最も重要なことになってきてる。提案された方法は、MMIOモデルの精度を改善することで、ファジングツールが組み込みファームウェアとどのようにやり取りするかを洗練させることを目指してる。無状態から有状態で適応可能なモデルに移行することで、ファジングツールがより多くのコードをカバーできるようになり、脆弱性を特定するのがより効果的になるんだ。
このプロセスは、ファームウェアのテストにおける適応型モデリングの重要性を示し、セキュリティテスト技術の改善の可能性を強調してる。組み込みシステムの進化が続く中で、堅牢なテスト方法の必要性はますます高まっていくから、ファームウェアファジングの進歩は重要な研究分野になるよ。
タイトル: ES-FUZZ: Improving the Coverage of Firmware Fuzzing with Stateful and Adaptable MMIO Models
概要: Grey-box fuzzing is widely used for testing embedded systems (ESes). The fuzzers often test the ES firmware in a fully emulated environment without real peripherals. To achieve decent code coverage, some state-of-the-art (SOTA) fuzzers infer the memory-mapped I/O (MMIO) behavior of peripherals from the firmware binary. We find the thus-generated MMIO models stateless, fixed, and poor at handling ES firmware's MMIO reads for retrieval of a data chunk. This leaves ample room for improving the code coverage. We propose ES-Fuzz to enhance the coverage of firmware fuzz-testing with stateful MMIO models that adapt to the fuzzer's coverage bottleneck. ES-Fuzz runs concurrently with a given fuzzer and starts a new run whenever the fuzzer's coverage stagnates. It exploits the highest-coverage test case in each run and generates new stateful MMIO models that boost the fuzzer's coverage at that time. We have implemented ES-Fuzz upon Fuzzware and evaluated it with 24 popular ES firmware. ES-Fuzz is shown to improve Fuzzware's coverage by up to $47\%$ and find new bugs in these firmware.
著者: Wei-Lun Huang, Kang G. Shin
最終更新: 2024-09-13 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2403.06281
ソースPDF: https://arxiv.org/pdf/2403.06281
ライセンス: https://creativecommons.org/licenses/by-nc-sa/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。