0xricksanchez/fisy-fuzzCeci est le framework complet de fuzzing du système de fichiers que j'ai présenté à la conférence Hack in the Box 2020 Lockdown Edition en avril.
Ceci est le framework complet de fuzzing de systèmes de fichiers que j'ai présenté à la conférence Hack in the Box 2020 Lockdown Edition en avril.
L'objectif de ce framework est de découvrir des bugs de sécurité du noyau sur les systèmes UNIX avec un fort accent sur les systèmes BSD. Il a été développé et largement testé contre FreeBSD, OpenBSD et NetBSD mais possède également un support mineur pour les hôtes basés sur Linux. Nous avons réussi à découvrir plus de 100 bugs uniques du noyau pour les systèmes de fichiers basés sur UFS et EXT tout en obtenant beaucoup d'informations sur l'ajout récent de ZFS.
Le makeFS2.py peut être utilisé comme utilitaire autonome pour générer différents systèmes de fichiers valides.
L'utilisation est expliquée en détail dans le dépôt de matériel de conférence
Le framework a été uniquement testé sur Ubuntu 18.04.
Il repose sur KVM, QEMU et libvirt.
Le script Requirements.sh installe toutes les dépendances nécessaires.
Le framework pourrait être entièrement fonctionnel sur la dernière version Ubuntu 20.04.
D'autres systèmes hôtes non basés sur apt devraient être facilement supportés et ne nécessitent que des modifications mineures dans Requirements.sh.
Une fois les prérequis satisfaits, vous pouvez continuer avec les étapes d'installation !
Reportez-vous au SETUP.md. Si certaines étapes ne sont pas claires, n'hésitez pas à demander !
Lancer le fuzzer ne nécessite que l'exécution de : python3 run.py.
Selon votre configuration, vous pouvez avoir besoin des privilèges sudo.
Lorsque tout a démarré avec succès, vous pouvez vous attacher à la session tmux de fuzzing via :
(sudo) tmux attach-session -t fsfuzzer
Le framework peut être configuré avec le script src/config/fuzzing_config.py :
# [fuzzing task specs]
# List of dictionaries specifying each fuzzing instance
fuzzer = [
{
"name": "fuzz1", # Some name for internal bookkeeping
"fs_creator_vm": "genBox", # Name as specified in libvirt for the VM handling the file system generation, can be the same across all instances
"fuzzing_vm": "fuzzBox_0", # Name as specified in libvirt for the VM handling the file system generation
"mutation_engine": "radamsa, 0", # Mutation Engine that is to be used, and size of mutation (radamsa takes no size argument)
"target_fs": "ufs2", # Target file system
"target_size": 15, # Max file system size in Megabyte
"populate_with_files": 10, # Amount of file that will be generated
"max_file_size": 1024, # Maximum file size in bytes for each generated file
"enable_dyn_scaling": False, # Dynamic scaling will increase the filesystem size periodically
},
]
# [credentials]
# Credentials for the root user for the VMs
# It is expected that these are the same across all instances, but not necessarily root
user = "root"
pw = "root"
Les moteurs de mutation disponibles sont :
La mise à l'échelle dynamique a été initialement implémentée pour tester si la taille d'un système de fichiers affecte les crashs possibles. Je n'ai pas pu identifier une valeur de déclenchement pour la taille du système de fichiers où les crashs changent, donc ce drapeau peut rester désactivé. Cela évite également une baisse de performance lors de longues exécutions, car les systèmes de fichiers plus grands prennent plus de temps à muter.
Les autres paramètres de configuration sont explicites.
La vidéo ci-dessous montre une démonstration rapide où deux instances de fuzzing ciblant FreeBSD avec un système de fichiers UFS2 muté par radamsa et un système de fichiers EXT à octets aléatoires inversés. Le système de fichiers UFS muté conduit directement à un crash, montrant à quelle vitesse vous pouvez planter un noyau.
Avec cette configuration, j'ai pu trouver plus de 100 bugs uniques du noyau dans FreeBSD, NetBSD et OpenBSD pour les systèmes de fichiers basés sur UFS et EXT. Parmi ces crashs, j'en ai eu un tas de très intéressants :
La majorité des crashs étaient des dénis de service du noyau. De plus, la majorité des crashs rencontrés ne sont toujours pas corrigés à ce jour (mai 2020). Alors lancez-vous dans la recherche de bugs du noyau dans les implémentations de systèmes de fichiers :).
Tout cela a été construit avec un 'développement basé sur la confiance', ce qui signifie qu'il a grandi bien trop vite à partir d'une simple idée de PoC. Par conséquent, il n'y a pas non plus de tests et très probablement quelques bugs. Je suis désolé si vous rencontrez des crashs (non liés à un kernel panic) mais n'hésitez pas à faire une PR ou à me contacter et je corrigerai les choses dès que possible !
Twitter: @0xricksanchez