Cette version du Challenge Project Exemplar vise à fournir aux concurrents un projet Challenge qui ressemble à la même structure et à la même interface qui existera pour tous les projets Challenge pendant la compétition.
Cet exemple a été développé et testé avec les versions suivantes :
Remarque : Le contenu du présent document est sujet à changement, veuillez le consulter et garder un œil sur les futures mises à jour !
src/ - voici le code source du projet challenge, noyau Linux 6.1.54 avec la modification suivante :
net/tipc/crypto.cnet/tipc/crypto.c , net/tipc/tipc_test.ctest_harnesses/ . run.sh - un script qui fournit à un CRS une interface standardisée pour interagir avec le projet de défi.
build.sh - un script qui définit le processus de construction du projet de défi.
project.yaml - un document yaml détaillant de nombreux aspects importants du projet de défi.
exemplar_only/ - ce dossier contient des informations supplémentaires qui ne sont fournies qu'avec la version exemplaire, ces informations ne devraient pas être fournies pendant le concours.
blobs/ - ce dossier contient un fichier appelé sample_solve.bin qui, une fois transmis au harnais de test, devrait déclencher la vulnérabilité injectée.patches/ - il s'agit d'un dossier qui contient deux exemples de correctifs.good_patch.diff - supprime la vulnérabilité et maintient la fonctionnalité.bad_patch.diff - supprime la vulnérabilité mais ne conserve pas la fonctionnalité.gen_blob.py - il s'agit d'un script d'aide permettant aux utilisateurs de générer des blobs binaires pour le harnais de test fourni.run_internal.sh - il s'agit d'un script qui s'exécute dans l'environnement Docker pour gérer les requêtes.setup.sh - il s'agit d'un script d'installation de dépendances pour créer l'image Docker.test_blob.py - il s'agit d'un script pour tester les blobs de données reçus par rapport aux harnais cibles. Pour tester l'exemple, créez d'abord l'image Docker de base en exécutant ce qui suit.
docker build . -t exemplar-cp-linux:base --target=exemplar-cp-linux-base Une fois construits, les interactions de base avec le conteneur peuvent être réalisées via le script run.sh
Le script run.sh fournit une interface standardisée qui sera cohérente sur tous les CP de la compétition. Avant de construire le logiciel, vous devez extraire la source de son référentiel source :
./run.sh pull_source Cette commande écrase tout ce qui se trouve actuellement dans le dossier src/ , permettant de charger de nouvelles copies du code source.
./run.sh build [patch file] La commande build crée le projet de défi avec un fichier de correctif généré facultatif. Le code source est construit via le volume docker monté dans le dossier src/ . Les binaires du faisceau de tests sont créés et stockés dans le dossier out/ . Et peut être utilisé pour l’analyse.
REMARQUE : la commande build construira l'état de fonctionnement actuel de src/ , ainsi que toutes les modifications apportées au Dockerfile. Si vous souhaitez tester un correctif, il est conseillé de créer une copie propre de l'état avec la commande pull_source et un Dockerfile propre.
./run.sh run_pov < blob_file > < harness_id > La commande run_pov exécute le fichier blob de données binaires fourni par rapport à l'ID de faisceau spécifié. Les ID de faisceau valides sont répertoriés dans le fichier project.yaml .
./run.sh run_tests La commande run_tests exécute les tests de fonctionnalité au sein du projet challenge. Désormais, la commande run_tests conservera l'état d'origine du répertoire src/ .
Disons que vous souhaitez extraire le code source, le construire tel quel et analyser le binaire de test Linux et exploiter le binaire qui en résulte.
./run.sh pull_source
./run.sh build
file out/linux_test_harness
file src/arch/x86/boot/bzImageVous exécutez ensuite un blob de données sur le faisceau de test pour vérifier les déclencheurs du désinfectant. Pour tester vos propres données d'entrée, remplacez le binaire exampler_only par votre propre fichier.
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger ' Après avoir vérifié les déclencheurs du désinfectant, vous modifiez le code source directement via le répertoire src/ , en essayant de corriger la vulnérabilité.
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_testsVous constatez que vous avez supprimé le déclencheur du désinfectant, mais que vous avez échoué aux tests de fonctionnalité. Vous créez une meilleure solution et générez un fichier de correctif. Vous extrayez une copie vierge de la source pour tester correctement le correctif par rapport à la source d'origine, puis réexécutez les tests pov et fonctionnels. Pour tester vos propres correctifs, remplacez le correctif exemplemplar_only par votre propre fichier.
./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 Vous avez maintenant généré un blob de données qui déclenche un désinfectant lorsqu'il est transmis au harnais linux_test_harness , ainsi qu'un correctif qui corrige cette vulnérabilité tout en réussissant les tests de fonctionnalité.
