Bases du fuzzing : entrées guidées par la couverture, corpus et tri des plantages

Ce que c'est

Le fuzzing alimente un programme avec des entrées générées pour trouver des plantages, des blocages et des assertions violées. Les fuzzers modernes sont guidés par la couverture : la documentation de Go décrit un moteur qui mute les entrées, conserve celles qui atteignent du nouveau code comme ajouts « intéressants » à un corpus, et rapporte les entrées en échec après les avoir minimisées. Une cible de fuzzing est une petite fonction qui prend des octets ou des arguments typés et appelle le code testé. La documentation de libFuzzer indique que le corpus devrait idéalement être amorcé avec une collection variée d'entrées valides et invalides, et que le fuzzer fonctionne sans amorces mais de façon moins efficace. OSS-Fuzz exécute en continu des fuzzers pour des projets open source avec les moteurs libFuzzer, AFL++, Honggfuzz et Centipede combinés à des sanitizers.

Pourquoi c'est important

Les analyseurs, décodeurs, gestionnaires de protocole et tout ce qui touche à des octets non fiables ont des cas limites que personne n'énumère : champs de longueur qui débordent, structures qui s'imbriquent plus profondément que la pile, encodages qui changent en cours de flux. Un fuzzer les explore mécaniquement, et avec des sanitizers, il détecte des erreurs mémoire qui passeraient autrement silencieusement. Dans les langages sûrs pour la mémoire, le gain se traduit par des panics, des boucles infinies, un épuisement de ressources et des invariants rompus.

Comment l'appliquer

• Choisir des cibles où l'entrée n'est pas fiable et où le code est rapide et déterministe ; la documentation de Go demande des cibles qui ne dépendent pas d'un état global, car elles s'exécutent dans des workers parallèles.
• Écrire la cible comme une vérification de propriété, pas seulement « ne plante pas » : aller-retour (decode(encode(x)) == x), comparaison avec une implémentation de référence, ou vérification d'invariants après l'appel.
• Amorcer le corpus avec des échantillons réels et le committer ; committer chaque entrée de plantage minimisée comme test de non-régression (Go écrit les entrées en échec dans testdata/fuzz/ et les exécute avec un go test ordinaire).
• Donner à la CI un budget court (une limite de temps ou d'itérations) et exécuter de longues sessions selon un calendrier ou via un service comme OSS-Fuzz ; minimiser le corpus périodiquement (-merge=1 dans libFuzzer) afin qu'il reste petit sans perdre de couverture.
• Construire les cibles C et C++ avec des sanitizers d'adresse et de comportement indéfini.

Pièges

Une cible qui lit des fichiers ou le réseau, ou qui est lente, affame le moteur. Le fuzzing trouve des plantages, pas des réponses fausses, à moins que la cible n'affirme quelque chose. Les cibles non déterministes produisent des rapports que personne ne peut reproduire. La documentation de Go note un délai d'une seconde par exécution, si bien qu'un chemin lent mais légitime est signalé comme un blocage. Un fuzzer ne prouve jamais l'absence de bogues ; il abaisse les probabilités des types de bogues qu'il peut déclencher.