La nouvelle a été publiée quee Amazon a publié un nouvel outil de fuzzing appelé Snapchange, qui permet de vérifier les fichiers exécutables sans les modifier et sans la présence du code source de l’application. Il s’agit d’une décision conçue en partie pour répondre aux préoccupations concernant la sécurité de la chaîne d’approvisionnement des logiciels.
Dans le post d’Amazon, il est mentionné que, Snapchange a commencé comme une expérience de l’équipe de recherche sur la sécurité open source AWS Find and Fix (F2) pour explorer le potentiel de l’utilisation de KVM pour activer le fuzzing d’instantanés.
Aujourd’hui, nous sommes ravis d’annoncer Snapchange, un nouveau projet open source pour rendre le fuzzing basé sur des instantanés beaucoup plus facile. Snapchange permet de fuzzer un binaire cible avec un minimum de modifications, fournissant des informations utiles qui facilitent le fuzzing.
Snapchange est un framework Rust permettant de créer des fuzzers qui lisent des instantanés de la mémoire physique pour augmenter l’efficacité et réduire la complexité du fuzzing de nombreux types de cibles. Snapchange utilise les fonctionnalités du gestionnaire de machines virtuelles intégré au noyau Linux, connu sous le nom de Kernel Virtual Machine, ou KVM.
À propos de Snapchange
Il est mentionné que, Snapchange permet de charger un vidage de mémoire physique avec un code exécutable dérivé et organiser, à l’aide de l’hyperviseur KVM, une exécution cyclique du code présent dans la décharge, itérer sur diverses combinaisons de données d’entréesuivi des défaillances ou anomalies émergentes et redémarrage de la vérification après la prochaine itération, chaque fois que le segment de mémoire et les registres du processeur sont restaurés à l’état d’origine.
Une itération se réinitialise et redémarre après une fin anormale, un temps d’attente ou la survenance d’un certain événement. Les données d’entrée sont remplacées directement dans la mémoire et pour économiser des ressources lors de l’initialisation à l’état initial de la mémoire, après avoir effectué l’itération suivante, il est déterminé quelles données sont en mémoire et ont changé.
Le vidage mémoire initial est créé en enregistrant un instantané de la machine virtuelle dans lequel l’environnement avec l’application testée est exécuté, s’exécutant sous VirtualBox ou QEMU La logique de substitution des données d’entrée est déterminée en créant des scripts spéciaux, et la position de départ de l’exécution cyclique est définie en définissant à partir d’un point d’arrêt dans le débogueur.
Par exemple, s’il est nécessaire de vérifier le traitement multi-états d’une requête réseau, le chercheur lance l’application sur le système invité dans VirtualBox ou QEMU, dans le débogueur trouve le début de l’exécution de la procédure de traitement de la requête (par exemple , après avoir appelé la fonction recv), place un point d’arrêt dessus et détermine la zone mémoire dans laquelle le paquet réseau reçu est chargé. Après cela, un instantané du système invité est créé et téléchargé sur Snapchange.
Pour vérification, un script est écrit qui écrit les données pendant l’énumération directement dans la mémoire tampon. du paquet réseau, qui permet de simuler le traitement de paquets réseau réels. Snapchange reprend là où il s’était arrêté, modifiant à chaque fois le contenu des données dans le tampon et réinitialisant l’état de la mémoire à son état d’origine.
Diverses stratégies sont prises en charge pour générer des données d’entrée. Plusieurs environnements liés à différents cœurs de processeur peuvent être énumérés avec une exécution parallèle. En plus de détecter les défaillances lors de l’exécution du code, il prend également en charge la collecte de mesures de performances, l’accumulation de statistiques de couverture pour évaluer la couverture du code exécutable et le suivi étape par étape du code exécutable.
Pour les intéressé par le projetVeuillez noter que le code du projet est écrit en Rust et est distribué sous la licence Apache 2.0 via GitHub.
Snapchange fonctionne sous Linux, mais nécessite un accès direct aux primitives KVM sous-jacentes. Par conséquent, il prend en charge les types d’instance EC2 bare metal, qui s’exécutent sans hyperviseur, mais pas les instances EC2 virtualisées.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter l’annonce originale sur le lien suivant.