Software Security @ EPFL, Spring 2025
このラボでは、GoogleのOSS-Fuzzインフラストラクチャ内で、tmuxターミナルマルチプレクサに対するファジング活動を強化しました。まず、既存のinput-fuzzerハーネスについて、提供されたシードコーパスを使用した場合と使用しない場合の両方で行カバレッジを評価し、初期カバレッジが同等であることを確認してベースラインを確立しました。次に、ベースラインファザーでは十分に実行されないtmux内の2つの重要なコード領域を特定しました。これらのカバレッジギャップに対処するため、cmd-fuzzerとargument-fuzzerという2つの新しいターゲットファジングハーネスを開発・評価し、これらの領域でのカバレッジを改善できることを実証しました。これらのファジング改善によってプロジェクト期間内に新たな重大な脆弱性は発見されなかったため、クラッシュ分析は既知の過去の脆弱性に焦点を当てました。CVE-2020-27347（スタックベースのバッファオーバーフロー）の概念実証（PoC）を開発し、その根本原因を分析し、実装された修正について議論し、そのセキュリティへの影響を評価しました。
このプロジェクトは、OSS-Fuzzフレームワークを利用して、tmuxオープンソースターミナルマルチプレクサにファジング技術を適用・強化することを目的としました。プロジェクトは以下の主要な段階で構成されました：
ベースライン評価（パート1）：
tmux用の既存のinput-fuzzerハーネスを理解し評価する。カバレッジギャップ分析（パート2）：
input-fuzzerによって十分に実行されていないtmux内の重要なコード領域を特定する。arguments.c）とコマンド解析・実行ロジック（cmd-parse.c、cmd-*.cモジュール）に焦点を当てる。ファザーの改善（パート3）：
argument-fuzzer：arguments.cのコマンドライン引数解析ロジックをテストするために特別に設計。cmd-fuzzer：コマンド解析および実行経路をテストするために設計され、cmd-parse.cおよびさまざまなcmd-*.cモジュールを対象とする。クラッシュ分析（パート4）：
tmuxの既知の既存脆弱性（CVE-2020-27347）を詳細な分析対象として選択した。最終提出物は次のように構成されています（submission/ディレクトリ内）：
submission/
├── README.md # このファイル
├── part_1/ # パート1のファイル: ベースライン評価
│ ├── oss-fuzz.diff # input-fuzzerのシードコーパスを削除するための差分
│ ├── project.diff # （パート1ではおそらく空または軽微）
│ ├── remove_seed_corpus.patch # 使用された実際のパッチファイル
│ ├── report/ # input-fuzzerのHTMLカバレッジレポート
│ │ ├── w_corpus/
│ │ └── wo_corpus/
│ ├── run.w_corpus.sh # コーパス付きでinput-fuzzerを実行するスクリプト
│ └── run.wo_corpus.sh # コーパスなしでinput-fuzzerを実行するスクリプト
├── part_3/ # パート3のファイル: ファザーの改善
│ ├── coverage_noimprove/ # ベースラインカバレッジ（例: コーパスなしのinput-fuzzerから）
│ │ └── ...
│ ├── improve1/ # 改善1: argument-fuzzer
│ │ ├── coverage_improve1/ # argument-fuzzerのカバレッジレポート
│ │ ├── oss-fuzz.diff # argument-fuzzer用のOSS-Fuzz設定変更
│ │ ├── project.diff # argument-fuzzer用のTmux変更（例: 新しい.cc、Makefile.am）
│ │ └── run.improve1.sh # argument-fuzzerを実行するスクリプト
│ └── improve2/ # 改善2: cmd-fuzzer
│ ├── coverage_improve2/ # cmd-fuzzerのカバレッジレポート
│ ├── oss-fuzz.diff # cmd-fuzzer用のOSS-Fuzz設定変更
│ ├── project.diff # cmd-fuzzer用のTmux変更
│ └── run.improve2.sh # cmd-fuzzerを実行するスクリプト
├── part_4/ # パート4のファイル: クラッシュ分析（CVE-2020-27347）
│ ├── environment/ # PoC用のDocker環境
│ │ ├── Dockerfile
│ │ ├── run_tmux_cve_test.sh # 主要なPoCテストロジック
│ │ ├── test_fixed.sh
│ │ └── test_vulnerable.sh
│ └── run.poc.sh # DockerイメージをビルドしてPoCテストを実行するスクリプト
└── report.pdf # 包括的なプロジェクトレポート
（注：scripts/ディレクトリに含まれる_run_fuzz_core.shはヘルパーであり、このREADMEがsubmission/と並んで実際のプロジェクトルートにある場合は、ルートの一部となります）
すべてのファジングキャンペーンとCVE PoCの再現は、シェルスクリプトによって調整されたDocker環境内で実行されるように設計されています。
すべてのファジングキャンペーンとCVE PoCの再現は、シェルスクリプトによって調整されたDocker環境内で実行されるように設計されています。
前提条件：
bashシェルとgitクライアント。oss-fuzzをクローンする必要がある場合（プロジェクトルートにoss-fuzz/が見つからない場合にクローンを試みます）、[email protected]用のSSHキーが設定されていること。または、https://github.com/google/oss-fuzz.gitを事前にプロジェクトルートにクローンしておくこともできます。一般的なスクリプトアーキテクチャ：
このプロジェクトは、集中化されたコアスクリプトscripts/_run_fuzz_core.sh（submission/ディレクトリには含まれていませんが、このREADMEが前提とするプロジェクト全体の構造の一部です）を使用します。submission/part_1/、submission/part_3/improve1/、submission/part_3/improve2/、およびsubmission/part_4/にある個々のランナースクリプトは、以下を担当します：
oss-fuzzリポジトリのクリーンチェックアウトに実行固有のoss-fuzz.diffパッチを適用して、特定のテスト環境をセットアップします（ほとんどのランナースクリプトから../../oss-fuzzにあると想定されます）。PROJECT、HARNESS、LABEL、プロジェクト固有パッチへのパス、出力ディレクトリなど）をエクスポートします。_run_fuzz_core.shスクリプトを呼び出します。このスクリプトは次を処理します：
tmuxに新しいファザーソースを追加するため）。submission/ディレクトリ構造内の指定された場所にコーパスとHTMLカバレッジレポートを生成してエクスポート。スクリプトの実行：
oss-fuzz/と出力ディレクトリの相対パスが正しく解決されるように、一般にプロジェクトのルートディレクトリからランナースクリプトを実行することをお勧めします。
1. パート1: ベースライン評価（input-fuzzer）
これらのスクリプトは、tmux用の既存のinput-fuzzerを評価します。
# プロジェクトのルートディレクトリから:
./submission/part_1/run.w_corpus.sh # デフォルトのシードコーパス付きでinput-fuzzerを実行
./submission/part_1/run.wo_corpus.sh # シードコーパスなしでinput-fuzzerを実行
run.w_corpus.shはシードに関するデフォルトのtmuxビルド動作を使用します。
run.wo_corpus.shはsubmission/part_1/remove_seed_corpus.patch（ローカルのoss-fuzz.diffを介して、このパッチを呼び出すかその変更を統合します）をoss-fuzz/projects/tmux/build.shに適用して、初期シードコーパスが使用されないようにします。カバレッジレポートはsubmission/part_1/report/w_corpus/とsubmission/part_1/report/wo_corpus/およびsubmission/part_1/report/wo_corpus/にそれぞれエクスポートされます。
2. パート3: ファザーの改善（input-fuzzer）
改善1（argument-fuzzer）: arguments.cを対象とします。
# プロジェクトのルートディレクトリから:
./submission/part_3/improve1/run.improve1.sh
改善2（cmd-fuzzer）: cmd-parse.cとコマンド実行を対象とします。
# プロジェクトのルートディレクトリから:
./submission/part_3/improve2/run.improve2.sh
各run.improveX.shスクリプトは、ローカルのoss-fuzz.diffを適用し、PROJECT_PATCH_FILEをローカルのproject.diff（新しいファザーコードをtmuxに追加し、Makefile.amを更新します）に設定します。カバレッジレポートは、それぞれのsubmission/part_3/improveX/coverage_improveX/ディレクトリにエクスポートされます。submission/part_3/coverage_noimprove/ディレクトリには、比較用のパート1のベースラインカバレッジが含まれています。
# プロジェクトのルートディレクトリから:
./submission/part_4/run.poc.sh
このスクリプトは、専用のDockerイメージ（submission/part_4/environment/Dockerfileから）をビルドし、tmux 3.1b（脆弱なバージョン）をパッチ適用済みコミットa868bacに対してテストします。
（詳細な説明、図、表は完全なreport.pdfにあります）
input-fuzzerにとってはわずかでした。arguments.c）、コマンド解析/実行（cmd-parse.c、cmd-*.c）、およびクライアント/サーバーロジック（client.c、server.c）は、ほとんど実行されていませんでした（例: arguments.cは約5.8%の行カバレッジ）。argument-fuzzer（arguments.cを対象）: arguments.cで66.62%の行カバレッジを達成し、約5.8%のベースラインから大幅に増加しました。cmd-fuzzer（コマンド解析と実行を対象）: cmd-parse.cの行カバレッジを42.58%（約27%から）に、関数カバレッジを77.78%に増加させました。arguments.cのカバレッジも45.54%に上昇しました。cmd.cは39.14%の行カバレッジに達しました。cmd-*.cモジュール（例: cmd-bind-key.c、cmd-set-options.cは50%の関数カバレッジ）およびキー処理ルーチン（key-string.cは30%の行カバレッジ、key-bindings.cは6.05%の行カバレッジ）で、新規または大幅に改善されたカバレッジを達成しました。\033[::::::7::1:2:3::5:6:7:mを使用して、tmux 3.1b（コミット6a33a12）でCVE-2020-27347（SGRエスケープシーケンス解析におけるスタックバッファオーバーフロー）を再現することに成功しました。a868bac（修正を含み、バージョン3.1cにつながる）がクラッシュの影響を受けないことを確認しました。argument-fuzzer、cmd-fuzzer）を開発するには、特定の未実行コードパスをターゲットにするために、tmuxの内部の引数およびコマンド処理ロジックをよく理解する必要がありました。cmd-fuzzerをさらに拡張して、より広範なcmd-*.cモジュール、特にウィンドウ、レイアウト、ペイン操作などの複雑な状態相互作用を扱うモジュールをカバーする。cmd-parse.yの文法定義を活用して、より構文的に有効で複雑なコマンドシーケンスを生成する可能性を探る。