google/aflamerican fuzzy lop - un fuzzer orienté sécurité
Initialement développé par Michal Zalewski [email protected].
Voir 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 éprouvées pour identifier des problèmes de sécurité dans des logiciels réels ; il est responsable de la vaste majorité des bugs d'exécution de code à distance et d'escalade de privilèges découverts à ce jour dans les logiciels critiques pour la sécurité.
Malheureusement, le fuzzing est également relativement superficiel ; des mutations aléatoires aveugles rendent très improbable l'atteinte de certains chemins de code dans le code testé, laissant certaines vulnérabilités hors de portée de cette technique.
De nombreuses tentatives ont été faites 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 repose sur des 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. Cette approche fonctionne exceptionnellement bien, mais exige qu'un tel corpus soit facilement disponible. De plus, les mesures de couverture de 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 de flux de programme (« exécution concolique »), l'exécution symbolique ou l'analyse statique. Toutes ces méthodes sont extrêmement prometteuses dans des contextes expérimentaux, 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 « stupide ».
American Fuzzy Lop est un fuzzer par force brute couplé à un algorithme génétique guidé par instrumentation, extrêmement simple mais d'une solidité à toute épreuve. Il utilise une forme modifiée de couverture d'arêtes pour détecter sans effort les changements subtils et à petite échelle 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,
Muter le fichier de manière répétée en utilisant une variété équilibrée et bien étudiée de stratégies de fuzzing traditionnelles,
Si l'une des mutations générées entraîne une nouvelle transition d'état enregistrée par l'instrumentation, ajouter la sortie mutée comme nouvelle entrée dans la file d'attente.
Aller en 2.
Les cas de test découverts sont également purgés périodiquement pour éliminer ceux qui ont été rendus obsolètes par des découvertes plus récentes et à plus haute couverture ; ils subissent également plusieurs autres étapes de minimisation de l'effort pilotées par l'instrumentation.
Comme résultat secondaire du processus de fuzzing, l'outil crée un petit corpus autonome de cas de test intéressants. Ceux-ci sont extrêmement utiles pour alimenter d'autres régimes de test exigeants en ressources ou en main-d'œuvre - par exemple, pour les tests de résistance des navigateurs, des applications bureautiques, des suites graphiques ou des outils à code source fermé.
Le fuzzer est minutieusement testé pour offrir des performances immédiates nettement supérieures au fuzzing aveugle ou aux outils basés uniquement sur la couverture.
Lorsque le code source est disponible, l'instrumentation peut être injectée par un outil compagnon qui fonctionne comme un remplacement direct de gcc ou clang dans tout processus de compilation standard pour du code tiers.
L'instrumentation a un impact sur les performances assez modeste ; combinée aux autres optimisations implémentées par afl-fuzz, la plupart des programmes peuvent être fuzzés aussi vite, voire plus vite, qu'avec les outils traditionnels.
La manière correcte de recompiler le programme cible peut varier selon les spécificités du processus de compilation, mais une approche quasi universelle serait :```shell $ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Pour les programmes C++, vous voudrez également définir `CXX=/path/to/afl/afl-g++`.
Les wrappers clang (afl-clang et afl-clang++) peuvent être utilisés de la même manière ;
les utilisateurs de clang peuvent également opter pour un mode d'instrumentation plus performant,
comme décrit dans llvm_mode/README.llvm.
Lors du test de bibliothèques, vous devez trouver ou écrire un programme simple qui lit
les données depuis stdin ou depuis un fichier et les transmet à la bibliothèque testée. Dans un
tel cas, il est essentiel de lier cet exécutable à une version statique de la
bibliothèque instrumentée, ou de s'assurer que le bon fichier .so est chargé au
runtime (généralement en définissant `LD_LIBRARY_PATH`). L'option la plus simple est une
compilation statique, généralement possible via :```shell
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Définir AFL_HARDEN=1 lors de l'appel de 'make' fera que le wrapper CC
activera automatiquement les options de durcissement du code qui facilitent la détection
de simples bugs mémoire. Libdislocator, une bibliothèque d'assistance incluse avec AFL (voir
libdislocator/README.dislocator) peut également aider à découvrir les problèmes de corruption du tas.
PS. Il est conseillé aux utilisateurs d'ASAN de consulter le fichier notes_for_asan.txt pour des mises en garde importantes.
Lorsque le code source n'est PAS disponible, le fuzzer offre un support expérimental pour l'instrumentation rapide et à la volée des binaires en boîte noire. Ceci est accompli avec une version de QEMU fonctionnant dans le mode moins connu d'"émulation d'espace utilisateur".
QEMU est un projet distinct d'AFL, mais vous pouvez facilement construire la fonctionnalité en faisant :```shell $ cd qemu_mode $ ./build_qemu_support.sh
Pour des instructions et mises en garde supplémentaires, voir qemu_mode/README.qemu.
Le mode est environ 2 à 5 fois plus lent que l'instrumentation au moment de la compilation, se prête moins bien à la parallélisation et peut présenter quelques autres particularités.
## 5) Choisir les cas de test initiaux
Pour fonctionner correctement, le fuzzer nécessite un ou plusieurs fichiers de départ contenant un bon exemple des données d'entrée normalement attendues par l'application ciblée. Il y a deux règles de base :
- Gardez les fichiers petits. Sous 1 kB est idéal, bien que ce ne soit pas strictement nécessaire.
Pour une discussion sur l'importance de la taille, voir [perf_tips.txt](https://github.com/google/afl/blob/master/docs/perf_tips.txt).
- N'utilisez plusieurs cas de test que s'ils sont fonctionnellement différents les uns des autres.
Il est inutile d'utiliser cinquante photos de vacances différentes pour fuzzer une bibliothèque d'images.
Vous pouvez trouver de nombreux bons exemples de fichiers de départ dans le sous-répertoire testcases/ fourni avec cet outil.
PS. Si un grand corpus de données est disponible pour le filtrage, vous pouvez utiliser l'utilitaire afl-cmin pour identifier un sous-ensemble de fichiers fonctionnellement distincts qui exercent différents chemins de code dans le binaire cible.