Ziel dieser Challenge Project Exemplar-Version ist es, den Teilnehmern ein Challenge-Projekt zur Verfügung zu stellen, das der gleichen Struktur und Schnittstelle ähnelt, die für alle Challenge-Projekte während des Wettbewerbs vorhanden sein wird.
Dieses Exemplar wurde mit folgenden Versionen entwickelt und getestet:
Hinweis: Der hierin enthaltene Inhalt kann sich ändern. Bitte ziehen Sie ihn zurück und halten Sie Ausschau nach zukünftigen Aktualisierungen!
src/ – dies ist der Quellcode für das Challenge-Projekt, Linux-Kernel 6.1.54 mit der folgenden Änderung:
net/tipc/crypto.c wieder eingeführtnet/tipc/crypto.c und net/tipc/tipc_test.c hinzugefügttest_harnesses/ wurde ein AIxCC-spezifischer Kabelbaum hinzugefügt. run.sh – ein Skript, das einem CRS eine standardisierte Schnittstelle zur Interaktion mit dem Challenge-Projekt bereitstellt.
build.sh – ein Skript, das den Build-Prozess für das Challenge-Projekt definiert.
project.yaml – ein Yaml-Dokument, das viele wichtige Aspekte des Challenge-Projekts detailliert beschreibt.
exemplar_only/ – Dieser Ordner enthält zusätzliche Informationen, die nur mit der Exemplarversion bereitgestellt werden. Es ist nicht zu erwarten, dass diese Informationen während des Wettbewerbs bereitgestellt werden.
blobs/ – dieser Ordner enthält eine Datei namens sample_solve.bin , die bei Übergabe an den Test-Harness die injizierte Schwachstelle auslösen sollte.patches/ – Dies ist ein Ordner, der zwei Beispiel-Patches enthält.good_patch.diff – beseitigt die Schwachstelle und behält die Funktionalität bei.bad_patch.diff – beseitigt die Schwachstelle, behält jedoch nicht die Funktionalität bei.gen_blob.py – Dies ist ein Hilfsskript für Benutzer zum Generieren von Binärblobs für die bereitgestellte Testumgebung.run_internal.sh – Dies ist ein Skript, das in der Docker-Umgebung ausgeführt wird, um Anfragen zu verarbeiten.setup.sh – Dies ist ein Abhängigkeitsinstallationsskript zum Erstellen des Docker-Images.test_blob.py – Dies ist ein Skript zum Testen empfangener Datenblobs anhand von Zielkabelbäumen. Um das Exemplar zu testen, erstellen Sie zunächst das Basis-Docker-Image, indem Sie Folgendes ausführen.
docker build . -t exemplar-cp-linux:base --target=exemplar-cp-linux-base Nach der Erstellung können grundlegende Interaktionen mit dem Container über das Skript run.sh erreicht werden.
Das run.sh -Skript stellt eine standardisierte Schnittstelle bereit, die für alle Wettbewerbs-CPs konsistent ist. Bevor Sie die Software erstellen, müssen Sie die Quelle aus ihrem Quell-Repository abrufen:
./run.sh pull_source Dieser Befehl überschreibt alles, was sich derzeit im Ordner src/ befindet, sodass neue Kopien des Quellcodes geladen werden können.
./run.sh build [patch file] Der build Befehl erstellt das Challenge-Projekt mit einer optional generierten Patch-Datei. Der Quellcode wird über das Docker-Volume erstellt, das im Ordner src/ gemountet ist. Die Test-Harness-Binärdateien werden erstellt und im Ordner out/ gespeichert. Und kann zur Analyse verwendet werden.
HINWEIS: Der build -Befehl erstellt den aktuellen Arbeitsstatus von src/ sowie alle Änderungen an der Docker-Datei. Wenn Sie einen Patch testen möchten, wird empfohlen, mit dem Befehl pull_source und einer sauberen Docker-Datei eine saubere Kopie des Status zu erstellen.
./run.sh run_pov < blob_file > < harness_id > Der Befehl run_pov führt die bereitgestellte Binärdaten-Blobdatei für die angegebene Harness-ID aus. Gültige Kabelbaum-IDs sind in der Datei project.yaml aufgeführt.
./run.sh run_tests Der Befehl run_tests führt die Funktionstests innerhalb des Challenge-Projekts aus. Ab sofort behält der Befehl run_tests den ursprünglichen Zustand des Verzeichnisses src/ bei.
Nehmen wir an, Sie möchten den Quellcode abrufen, ihn so erstellen, wie er ist, und die resultierende Linux-Testbinärdatei analysieren und die daraus resultierende Binärdatei nutzen.
./run.sh pull_source
./run.sh build
file out/linux_test_harness
file src/arch/x86/boot/bzImageAnschließend führen Sie einen Datenblob für die Testumgebung aus, um die Desinfektionsauslöser zu überprüfen. Um Ihre eigenen Eingabedaten zu testen, ersetzen Sie die Binärdatei exemplar_only durch Ihre eigene Datei.
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger ' Nachdem Sie die Sanitizer-Trigger überprüft haben, ändern Sie den Quellcode direkt über das Verzeichnis src/ und versuchen, die Schwachstelle zu patchen.
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_testsSie stellen fest, dass Sie den Desinfektionsauslöser entfernt haben, aber die Funktionstests nicht bestanden haben. Sie erstellen eine bessere Lösung und generieren eine Patchdatei. Sie ziehen eine saubere Kopie der Quelle, um den Patch ordnungsgemäß mit der Originalquelle zu testen, und führen die POV- und Funktionstests erneut aus. Um Ihre eigenen Patches zu testen, ersetzen Sie den exemplar_only-Patch durch Ihre eigene Datei.
./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 Sie haben jetzt einen Datenblob generiert, der bei Übergabe an den linux_test_harness Harness einen Sanitizer auslöst, sowie einen Patch, der diese Schwachstelle behebt, während Funktionstests durchgeführt werden.
