このチャレンジ プロジェクトの模範リリースは、競技会期間中のすべてのチャレンジ プロジェクトに存在するのと同じ構造とインターフェイスに似たチャレンジ プロジェクトを競技者に提供することを目的としています。
このサンプルは、次のバージョンで開発およびテストされています。
注: ここに記載されている内容は変更される可能性があります。今後の更新に注目してください。
src/ - これは、チャレンジ プロジェクトのソース コードです。Linux カーネル 6.1.54 に次の変更を加えたものです。
net/tipc/crypto.cへの変更により CVE-2021-43267 が再導入されましたnet/tipc/crypto.c 、 net/tipc/tipc_test.cへの変更により、脆弱な機能の kunit テストを追加しました。test_harnesses/フォルダーに追加しました。run.sh - チャレンジ プロジェクトと対話するための標準化されたインターフェイスを CRS に提供するスクリプト。
build.sh - チャレンジ プロジェクトのビルド プロセスを定義するスクリプト。
project.yaml - チャレンジ プロジェクトの多くの重要な側面を詳細に説明する yaml ドキュメント。
exemplar_only/ - このフォルダーには、exemplar リリースでのみ提供される補足情報が含まれています。この情報は、コンテスト中に提供されることは期待できません。
blobs/ - このフォルダーには、 sample_solve.binというファイルが含まれており、このファイルがテスト ハーネスに渡されると、挿入された脆弱性がトリガーされます。patches/ - これは 2 つのサンプル パッチを含むフォルダーです。good_patch.diff - 脆弱性を削除し、機能を維持します。bad_patch.diff - 脆弱性は削除されますが、機能は維持されません。gen_blob.py - これは、ユーザーが提供されたテスト ハーネス用のバイナリ BLOB を生成するためのヘルパー スクリプトです。run_internal.sh - これは、リクエストを処理するために Docker 環境内で実行されるスクリプトです。setup.sh - これは、Docker イメージを構築するための依存関係インストール スクリプトです。test_blob.py - これは、受信したデータ BLOB をターゲット ハーネスに対してテストするためのスクリプトです。 エグザンプラをテストするには、まず次のコマンドを実行してベースの Docker イメージを構築します。
docker build . -t exemplar-cp-linux:base --target=exemplar-cp-linux-baseビルドが完了すると、 run.shスクリプトを介してコンテナーとの基本的な対話を行うことができます。
run.shスクリプトは、すべての競合 CP にわたって一貫した標準化されたインターフェイスを提供します。ソフトウェアをビルドする前に、ソース リポジトリからソースをプルする必要があります。
./run.sh pull_sourceこのコマンドは、現在src/フォルダー内にあるものを上書きし、ソース コードの新しいコピーをロードできるようにします。
./run.sh build [patch file] buildコマンドは、オプションで生成されたパッチ ファイルを使用してチャレンジ プロジェクトをビルドします。ソース コードは、 src/フォルダーにマウントされた Docker ボリュームを介してビルドされます。テスト ハーネス バイナリはビルドされ、 out/フォルダーに保存されます。そして分析に使用することができます。
注: buildコマンドは、 src/の現在の動作状態と、Dockerfile への変更をビルドします。パッチをテストしたい場合は、 pull_sourceコマンドとクリーンな Dockerfile を使用して状態のクリーンなコピーを作成することをお勧めします。
./run.sh run_pov < blob_file > < harness_id > run_povコマンドは、指定されたハーネス ID に対して、提供されたバイナリ データ BLOB ファイルを実行します。有効なハーネス ID は、 project.yamlファイルにリストされています。
./run.sh run_tests run_testsコマンドは、チャレンジ プロジェクト内で機能テストを実行します。現時点では、 run_testsコマンドはsrc/ディレクトリの元の状態を保存します。
ソース コードを取得してそのままビルドし、その結果得られる Linux テスト バイナリとハーネス バイナリを分析するとします。
./run.sh pull_source
./run.sh build
file out/linux_test_harness
file src/arch/x86/boot/bzImage次に、テスト ハーネスに対してデータ BLOB を実行して、サニタイザーのトリガーを確認します。独自の入力データをテストするには、exemplar_only バイナリを独自のファイルに置き換えます。
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger 'サニタイザーのトリガーを確認した後、 src/ディレクトリを介してソース コードを直接変更し、脆弱性へのパッチの適用を試みます。
sed -i ' 2310,2312d ' src/net/tipc/crypto.c
./run.sh build
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger '
./run.sh run_testsサニタイザー トリガーを削除したことがわかりましたが、機能テストに不合格でした。より良いソリューションを作成し、パッチ ファイルを生成します。ソースのクリーン コピーを取得して、元のソースに対してパッチを適切にテストし、pov テストと機能テストを再実行します。独自のパッチをテストするには、exemplar_only パッチを独自のファイルに置き換えます。
./run.sh pull_source
./run.sh build exemplar_only/patches/good_patch.diff
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger '
./run.sh run_testsこれで、 linux_test_harnessハーネスに渡されたときにサニタイザーをトリガーするデータ BLOB と、機能テストに合格しながらその脆弱性を修正するパッチが生成されました。
