GitHub Security Lab a présenté le fonctionnement d’un projet open source appelé Fuzzing Taskflow, conçu pour automatiser une grande partie des tests de projets C/C++ au moyen du fuzzing et d’agents fondés sur des modèles linguistiques. Lorsqu’il est dirigé vers un dépôt GitHub, le workflow peut analyser le système de compilation, identifier les points d’entrée appropriés, créer des fuzz harnesses, lancer AFL++, lire les rapports de couverture, améliorer les outils, trier les crashs et préparer un rapport distinct pour chaque problème potentiel.
Le projet repose sur le framework GitHub Security Lab Taskflow Agent, qui exprime le workflow sous la forme d’un ensemble de tâches exécutées de bout en bout par l’agent. L’auteur de l’article, Antonio Morales, précise que l’objectif n’est pas de supprimer le rôle du chercheur, mais de transférer à l’agent les tâches répétitives qui consomment beaucoup de temps, tout en maintenant une séparation entre les décisions et l’exécution.
Comment le workflow fonctionne-t-il ?
L’utilisation commence à partir du dépôt du projet, par exemple en exécutant la commande ./scripts/fuzzing/run_fuzzing.sh PROJECT dans un Codespace. Le workflow installe les outils, clone le dépôt, analyse les fonctions importantes, puis crée des cibles de fuzzing et lance des campagnes sur celles-ci. Son architecture comprend un lanceur shell, des fichiers YAML décrivant les étapes du travail et les instructions adressées au modèle, ainsi que des outils MCP qui exécutent des opérations telles que le lancement d’AFL, la compilation des outils, la lecture de la couverture et le stockage des crashs.
L’agent n’appelle pas directement AFL ou clang : il décide de ce qui doit être testé et de la lacune de couverture qui mérite un suivi, tandis que les outils MCP exécutent les opérations de bas niveau. L’état est stocké dans une base SQLite appelée fuzz_context.db, ce qui permet de transmettre les résultats entre les étapes sans dépendre d’une mémoire partagée.
Boucle d’amélioration de la couverture
Chaque harness est compilé deux fois : une version .afl pour piloter AFL à l’aide des outils d’instrumentation appropriés, et une version .cov pour rejouer la liste des entrées et mesurer la couverture des lignes et des branches. Après chaque cycle, l’agent examine les branches non couvertes, puis choisit une action telle que l’ajout d’un nouveau seed, la modification du code source du harness pour appeler une autre interface, l’enrichissement du dictionnaire AFL avec les valeurs vérifiées par le code, ou l’abandon d’un chemin froid dont le coût ne se justifie pas.
Le budget de temps double, passant de 30 à 60, 120, 240, 480 puis 960 secondes, soit environ 32 minutes par cible au maximum indiqué. Le workflow s’arrête lorsqu’il constate une baisse du rendement : si deux cycles consécutifs produisent moins d’un point de pourcentage de couverture des lignes, selon la valeur par défaut configurable, il passe à une autre cible.
Gestion des entrées et des crashs
Le workflow prend en charge des mécanismes spécialisés pour les formats JSON et XML, les expressions régulières, PNG et le format binaire TLV à longueurs intégrées. Il peut également générer un dictionnaire à partir des constantes de chaînes et de nombres présentes dans les fichiers C et H. Ce dictionnaire est en outre enrichi après chaque étape de couverture, en fonction des contrôles proches des lignes non couvertes. Chaque harness conserve également un répertoire corpus stable et utilise afl-cmin pour en réduire la taille tout en conservant les entrées utiles entre les cycles et les campagnes.
Après la fin de la campagne, les crashs sont minimisés à l’aide d’afl-tmin, puis rejoués sous AddressSanitizer avant que les doublons ne soient supprimés en fonction de l’empreinte du sommet de la pile. Le workflow reteste également les crashs connus afin de vérifier l’effet des correctifs et classe les résultats dans des catégories comprenant : vulnérabilité, renforcement de la bibliothèque, erreur dans le harness, épuisement de la mémoire, délai d’attente, échec d’une assertion ou doublon.
Pourquoi cette information est-elle importante ?
L’intérêt pratique réside dans le fait que le workflow tente d’automatiser la boucle qui limite souvent l’efficacité du fuzzing continu : écrire des harnesses, lire la couverture, choisir la lacune suivante et trier les crashs. Cela pourrait réduire le coût initial des tests d’un projet qui n’a encore jamais fait l’objet de fuzzing, ou contribuer à élargir la couverture d’un projet existant.
Mais GitHub Security Lab pose une restriction essentielle : le workflow exécute directement sur le système hôte afl-fuzz, clang et les commandes de compilation choisies par le modèle, sans conteneur séparé. Un agent affecté par une injection d’instructions pourrait donc exécuter tout ce que l’utilisateur est en mesure d’exécuter. Le projet recommande de le lancer dans un environnement jetable, comme un Codespace ou une machine virtuelle temporaire, et sans privilèges élevés.
Les rapports de vulnérabilités et les correctifs proposés ne constituent pas non plus des résultats définitifs. L’article souligne que l’analyse du modèle peut être erronée et que le correctif proposé est marqué comme nécessitant une révision. Ainsi, Fuzzing Taskflow représente un point de départ bien préparé pour le chercheur, et non un substitut à la vérification humaine de l’accessibilité, de l’exploitabilité et de la cause racine.