Google a introduit le projet ClusterFuzzLite, qui permet d'organiser des tests de fuzzing du code pour une détection précoce des vulnérabilités potentielles lors du fonctionnement des systèmes d'intégration continue. Actuellement, ClusterFuzz peut être utilisé pour automatiser les tests fuzz des demandes d'extraction dans GitHub Actions, Google Cloud Build et Prow, mais la prise en charge d'autres systèmes CI est attendue à l'avenir. Le projet est basé sur la plateforme ClusterFuzz, créée pour coordonner le travail des clusters de tests de fuzzing, et est distribué sous licence Apache 2.0.
Il est à noter qu'après que Google a introduit le service OSS-Fuzz en 2016, plus de 500 projets open source importants ont été acceptés dans le programme de tests continus de fuzzing. Sur la base des tests effectués, plus de 6500 21 vulnérabilités confirmées ont été éliminées et plus de XNUMX XNUMX erreurs ont été corrigées. ClusterFuzzLite continue de développer des mécanismes de test de fuzzing avec la capacité d'identifier les problèmes plus tôt lors de la phase d'examen des modifications proposées. ClusterFuzzLite a déjà été implémenté dans les processus d'examen des modifications dans les projets systemd et curl, et a permis d'identifier les erreurs manquées par les analyseurs statiques et les linters utilisés au stade initial de la vérification du nouveau code.
ClusterFuzzLite prend en charge l'évaluation de projets en C, C++, Java (et autres langages basés sur JVM), Go, Python, Rust et Swift. Les tests de fuzzing sont effectués à l'aide du moteur LibFuzzer. Les outils AddressSanitizer, MemorySanitizer et UBSan (UndefinedBehaviorSanitizer) peuvent également être appelés pour identifier les erreurs et anomalies de mémoire.
Principales fonctionnalités de ClusterFuzzLite : vérification rapide des modifications proposées pour rechercher les erreurs avant l'acceptation du code ; télécharger des rapports sur les conditions d'accident ; la possibilité de passer à des tests de fuzzing plus avancés pour identifier des erreurs plus profondes qui ne sont pas apparues après avoir vérifié les modifications du code ; génération de rapports de couverture pour évaluer la couverture du code pendant les tests ; architecture modulaire qui vous permet de sélectionner les fonctionnalités requises.
Rappelons que le test de fuzzing consiste à générer un flux de toutes sortes de combinaisons aléatoires de données d'entrée proches des données réelles (par exemple, des pages html avec des paramètres de balises aléatoires, des archives ou des images avec des titres anormaux, etc.), et à enregistrer possible échecs dans le processus de leur traitement. Si une séquence plante ou ne correspond pas à la réponse attendue, ce comportement indique très probablement un bug ou une vulnérabilité.
Source: opennet.ru