[論文レビュー] Fuzzm: Finding Memory Bugs through Binary-Only Instrumentation and Fuzzing of WebAssembly

Daniel Lehmann, Martin Toldam Torp+1 more|arXiv (Cornell University)|Oct 28, 2021

Security and Verification in Computing被引用数 6

ひとこと要約

Fuzzmは、スタックおよびヒープのキャノニカルインストルメンテーションと効率的なカバレッジフィードバック、AFLスタイルの入力生成を組み合わせた、WebAssembly用の最初のバイナリオンリーブラウザブルーグレイボックスファズファーファイルである。Fuzzmはソースコードなしで本番環境のWebAssemblyバイナリにメモリバグを検出でき、実世界のバイナリで数十件のクラッシュを引き起こし、低遅延のバイナリハードニングを可能にし、攻撃を防ぐ。

ABSTRACT

WebAssembly binaries are often compiled from memory-unsafe languages, such as C and C++. Because of WebAssembly's linear memory and missing protection features, e.g., stack canaries, source-level memory vulnerabilities are exploitable in compiled WebAssembly binaries, sometimes even more easily than in native code. This paper addresses the problem of detecting such vulnerabilities through the first binary-only fuzzer for WebAssembly. Our approach, called Fuzzm, combines canary instrumentation to detect overflows and underflows on the stack and the heap, an efficient coverage instrumentation, a WebAssembly VM, and the input generation algorithm of the popular AFL fuzzer. Besides as an oracle for fuzzing, our canaries also serve as a stand-alone binary hardening technique to prevent the exploitation of vulnerable binaries in production. We evaluate Fuzzm with 28 real-world WebAssembly binaries, some compiled from source and some found in the wild without source code. The fuzzer explores thousands of execution paths, triggers dozens of crashes, and performs hundreds of program executions per second. When used for binary hardening, the approach prevents previously published exploits against vulnerable WebAssembly binaries while imposing low runtime overhead.

研究の動機と目的

• CやC++などの安全でない言語からコンパイルされたWebAssemblyバイナリにおけるメモリバグの増加するセキュリティリスクに対処すること。
• スタックキャノニカルやページ保護などの組み込みのメモリセーフティ機構が欠如しているWebAssemblyの特性により、ネイティブコードに比べて攻撃がより容易になるという点を克服すること。
• 既存のファズファーワークフローと互換性を持つバイナリオンリーファイルインストルメンテーションおよびフィードバックパイプラインを設計することで、ソースコードなしで効果的なWebAssemblyバイナリのファズファリングを可能にすること。
• 実用的で効率的かつデプロイ可能なソリューションを提供し、本番環境のWebAssemblyバイナリにおけるメモリバグの検出とバイナリハードニングを実現すること。

提案手法

• 実行時におけるオーバーフローおよびアンダーフローの検出を目的としたスタックおよびヒープキャノニカルインストルメンテーションをWebAssemblyバイナリに適用し、ファズファリングのオラクルおよびバイナリハードニング機構として機能させる。
• コンパイラが挿入したコードやアーキテクチャ固有の動的バイナリインストルメンテーションに依存しない、軽量でバイナリオンリーファイルのカバレッジインストルメンテーションを実装する。
• AFLの入力生成エンジンをWebAssembly仮想マシンに統合し、WebAssemblyバイナリの効率的で高スルーレートのファズファリングを可能にする。
• ファズファーファイルとターゲットプログラムの両方を1つのアドレス空間に配置することで、オーバーヘッドを低減し、効率的なフィードバック収集を可能にする。
• ヒープバッファのデアロケーション時にキャノニカルチェックを適用することで、パフォーマンスコストを最小限に抑えつつも、エクスプロイト検出能力を維持する。
• 28個の実世界のWebAssemblyバイナリ（ソースコードからコンパイルされたものと、実世界で見つかった第三者提供のもの）を対象に、アプローチの妥当性を検証した。

実験結果

リサーチクエスチョン

• RQ1 ソースコードにアクセスできない状況下でも、バイナリオンリーファズファーファイルは、WebAssemblyバイナリにおけるメモリバグを効果的に検出できるか？
• RQ2 標準的なコンパイラの緩和措置が存在しない状況下でも、キャノニカルベースのインストルメンテーションは、WebAssemblyバイナリにおけるスタックおよびヒープのオーバーフローをどれほど効果的に検出できるか？
• RQ3 コンパイラが挿入したインストルメンテーションに依存せずに、WebAssemblyバイナリに効率的にカバレッジインストルメンテーションを適用できるか？
• RQ4 提案されたインストルメンテーションのパフォーマンスオーバーヘッドはどの程度で、高スルーレートのファズファリング（例：1秒間に数百回の実行）をサポートできるか？
• RQ5 ファズファリングに使用する同じインストルメンテーションが、既知の脆弱性を有するバイナリを保護する実用的なバイナリハードニング技術としても機能するか？

主な発見

• Fuzzmは28個の実世界のWebAssemblyバイナリで数十件のクラッシュを引き起こし、メモリバグの発見における有効性を実証した。
• ファズファーファイルは1秒間に数百回のプログラム実行を達成しており、ネイティブコードに比べてWebAssembly固有のパフォーマンスオーバーヘッドがあるにもかかわらず、実用的であることが示された。
• キャノニカルインストルメンテーションはスタックおよびヒープのオーバーフローの両方を検出でき、特にWebAssemblyの線形メモリモデル上では、スタックからヒープデータへのオーバーフローが通常は検出されない場合でも、これを検出できた。
• カバレッジインストルメンテーションはAFLスタイルの入力生成に有効なフィードバックを提供し、ターゲットバイナリで数千の実行パスを探索するのを可能にした。
• 同じキャノニカルインストルメンテーションは、脆弱なWebAssemblyバイナリに対する以前に発表されたエクスプロイトを、単体のハードニング技術として効果的に防止した。
• このアプローチは低ランタイムオーバーヘッドを伴い、リコンパイルなしで既存のバイナリを保護できるため、本番環境へのデプロイに適している。