nccgroup/triforceaflAFL/QEMU fuzzing avec émulation du système complet.
Nouveau : pour ceux qui souhaitent jouer avec TriforceAFL et TLSF, Richard Johnson a créé un Dockerfile qui installe les deux (et compile même un noyau Linux pour vous). Il est disponible ici https://hub.docker.com/r/moflow/afl-triforce/tags/.
Autre nouveauté : afl-tmin fonctionne désormais avec le forkserver !
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Ceci est une version patchée d'AFL qui prend en charge le fuzzing système complet avec QEMU. Le QEMU inclus a été mis à jour pour permettre le traçage des branches lors de l'exécution d'un émulateur système pour x86_64. Des instructions supplémentaires ont été ajoutées pour démarrer le forkserver d'AFL, définir les paramètres de fuzz et marquer le début et la fin des cas de test.
Remarque : tous les outils AFL n'ont pas été testés avec les nouvelles modifications. Ces outils ont fait l'objet de quelques tests :
Pour compiler :
make
Pour obtenir une carte de couverture :
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Pour fuzzer :
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Remarque : contrairement à l'utilisation de l'option « -Q », vous devez spécifier la ligne de commande complète à afl-qemu-system-trace lorsque vous utilisez l'option « -QQ »).
Pour plus de détails sur l'utilisation de cette version modifiée d'AFL, consultez notre fuzzer d'appels système Linux à l'adresse https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Nouveaux drapeaux AFL : -QQ - utilise qemu en émulation système complet plutôt qu'en mode utilisateur (-Q)
Nouveaux drapeaux QEMU : -aflFile - Le nom du fichier contenant les entrées du fuzzer -aflPanicAddr - Une adresse de la fonction de panic du noyau pour la détection de panic -aflDmesgAddr - Adresse noyau Linux de la fonction de journalisation dmesg pour détecter la journalisation et intercepter les messages de journal
Nouvelles instructions QEMU : 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Démarre le serveur de fork d'AFL. Après ce point, chaque test s'exécutera dans un enfant forké séparé. Si enableTicks est non nul, QEMU réactivera la minuterie du CPU après le fork d'un enfant ; sinon, elle ne sera pas activée. edi=2 getWork(esi=ptr, edx=sz) Remplit ptr[0..sz] avec le prochain cas de test d'entrée. Renvoie la taille réellement remplie (<= sz). edi=3 startWork(esi=ptr) Demande à AFL de commencer le traçage. L'argument pointe vers un tampon contenant deux quadmots donnant les adresses de début et de fin du code à tracer. Les instructions en dehors de cette plage ne sont pas tracées. edi=4 doneWork(esi=exitCode) Indique à AFL que le cas de test est terminé. Si une panic est détectée, AFL arrête immédiatement le cas de test. Sinon, il s'exécute jusqu'à ce que doneWork soit appelé. Le code de sortie spécifié est renvoyé à AFL. (Le code peut, mais ne le fait actuellement pas, appliquer un OU avec la valeur 64 à tous les codes de sortie si des journaux dmesg ont été détectés pendant le cas de test.)
Nouveau pilote de bloc QEMU : -drive filename=privmem: Ce pilote de bloc conserve l'image du disque dans une mémoire en copie à l'écriture (copy-on-write), de sorte que les modifications ne sont jamais persistées sur le disque. Les modifications apportées par un cas de test sont isolées des autres cas de test.
Écrit et maintenu par Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Tous droits réservés. Distribué selon les termes et conditions de la licence Apache, version 2.0.
Pour les nouvelles versions et des informations supplémentaires, consultez : http://lcamtuf.coredump.cx/afl/
Pour échanger avec d'autres utilisateurs ou être informé des nouvelles fonctionnalités majeures, envoyez un courriel à [email protected].
** Consultez QuickStartGuide.txt si vous n'avez pas le temps de lire ce fichier. **
Le fuzzing est l'une des stratégies les plus puissantes et les plus éprouvées pour identifier les problèmes de sécurité dans les logiciels réels ; il est à l'origine de la grande majorité des bogues d'exécution de code à distance et d'élévation de privilèges découverts à ce jour dans les logiciels critiques pour la sécurité.
Malheureusement, le fuzzing est aussi relativement superficiel ; des mutations aveugles et aléatoires rendent très improbable l'atteinte de certains chemins de code dans le code testé, laissant certaines vulnérabilités totalement hors de portée de cette technique.
Il y a eu de nombreuses tentatives pour résoudre ce problème. L'une des premières approches - initiée par Tavis Ormandy - est la distillation de corpus. La méthode s'appuie sur les signaux de couverture pour sélectionner un sous-ensemble de graines intéressantes à partir d'un corpus massif et de haute qualité de fichiers candidats, puis les fuzzer par des moyens traditionnels. L'approche fonctionne exceptionnellement bien, mais nécessite qu'un tel corpus soit facilement disponible. De plus, les mesures de couverture par blocs ne fournissent qu'une compréhension très simpliste de l'état du programme et sont moins utiles pour guider l'effort de fuzzing sur le long terme.
D'autres recherches plus sophistiquées se sont concentrées sur des techniques telles que l'analyse du flux de programme (« exécution concolique »), l'exécution symbolique ou l'analyse statique. Toutes ces méthodes sont extrêmement prometteuses dans un cadre expérimental, mais tendent à souffrir de problèmes de fiabilité et de performance en usage pratique - et n'offrent actuellement pas d'alternative viable aux techniques de fuzzing « aveugle ».
American Fuzzy Lop est un fuzzer par force brute couplé à un algorithme génétique d'une simplicité extrême mais d'une solidité à toute épreuve, guidé par l'instrumentation. Il utilise une forme modifiée de couverture d'arêtes pour détecter sans effort les changements subtils et localisés du flux de contrôle du programme.
En simplifiant un peu, l'algorithme global peut se résumer ainsi :
Charger les cas de test initiaux fournis par l'utilisateur dans la file d'attente,
Prendre le fichier d'entrée suivant dans la file d'attente,
Tenter de réduire le cas de test à la plus petite taille qui ne modifie pas le comportement mesuré du programme,
