URL: https://linuxfr.org/users/woffer/journaux/fuzzing-eprouver-les-entrees-de-vos-developpements Title: Fuzzing : éprouver les entrées de vos développements Authors: woffer 🐧 Date: 2015年10月27日T19:16:54+01:00 License: CC By-SA Tags: fuzzing, développement, heartbleed, shellshock et lwn Score: 40 Wikipedia donne pour le fuzzing, la définition suivante (https://fr.wikipedia.org/wiki/Fuzzing) :> Le fuzzing (ou test à données aléatoires) est une technique pour tester des logiciels. L'idée est d'injecter des données aléatoires dans les entrées d'un programme. Si le programme échoue (par exemple en plantant ou en générant une erreur), alors il y a des défauts à corriger. Exemples de points d'entrée d'un programme :> - Fichiers> - Périphériques (clavier, souris, etc.)> - Variables d'environnement> - Réseau> - Limitation des ressources (mémoire, disque dur, temps CPU, etc.)> - etc. Cette définition montre bien, que la difficulté est de bien générer des jeux de données (aléatoires ou semi aléatoire) permettant de mettre à défaut son logiciel. Jusqu'à récemment, il existait deux catégories d'outils de fuzzing : - ceux utilisant la force brute - et ceux partant d'un profil de test bien particulier Le problème des outils utilisant la force brute est qu'ils ne permettent pas de trouver des cas complexes de crash dans un temps fini. Le problème des outils utilisant des profils de test est qu'ils nécessitent une connaissance approfondie du logiciel à tester et généralement permettent de ne trouver que les types d'erreurs que l'on souhaite chercher. ![AFL](http://lcamtuf.coredump.cx/afl/afl_screen.png) Comme le montre cet article http://lwn.net/Articles/657959/, depuis septembre 2014 et la découverte du problème Shellshock dans bash (problème existant depuis 25 ans ! avec la livraison de la version 1.03 de bash en 1989), un chercheur en sécurité de chez Google a trouvé un nouvelle stratégie pour effectuer du fuzzing en force brute mais de façon plus efficace. E il a développé l'outil American Fuzzy Lop (en C), qui a permis de : - découvrir le Shellshock de bash (une faille de 25 ans), - découvrir des denial-of-service sur le serveur DNS Bind - de redécouvrir la célèbre faille Heartbleed sur OpenSSL (attaque réputé complexe et qu'il a trouvé en seulement 6 heures de fuzzing) - et d'autres Actuellement, il existe des déclinaisons de cet outil pour les langages suivants : - Go (https://github.com/dvyukov/go-fuzz) (cf. ci-desous) - Python (https://bitbucket.org/jwilk/python-afl) - Rust (https://github.com/frewsxcv/afl.rs) - GCJ Java(https://gcc.gnu.org/java/) Ces outils fonctionnent de la façon suivante, ils vont : - instrumentaliser votre logiciel à tester afin "d'observer ses réactions" - injecter des trames aléatoires basées sur des corpus utilisés lors de vos tests unitaires par exemple - s'il détecte une nouveau de chemin d'exécution de votre logiciel, il va enrichir le corpus (initialement composé de vos tests unitaire) et se basé sur cette entrée pour générer de nouvelles trames aléatoires. - s'il identifie un crash/exception/panic/boucle infinie/fuite mémoire, il trace l'entrée et l'éventuelle stack-trace pour correction ultérieure.