La société Google a présenté le projet ClusterFuzzLite, permettant d'organiser des tests de fuzzing du code pour détecter précocement d'éventuelles vulnérabilités lors du fonctionnement des systèmes d'intégration continue. Actuellement, ClusterFuzz peut être utilisé pour automatiser les tests de fuzzing des pull requests dans GitHub Actions, dans Google Cloud Build et dans Prow, mais il est prévu dans le futur qu'un support pour d'autres systèmes CI soit également mis en place. Le projet est basé sur la plateforme ClusterFuzz, créée pour coordonner le travail des clusters de tests de fuzzing, et est distribué sous la licence Apache 2.0.
Il est noté qu'après son lancement en 2016 par Google, le service OSS-Fuzz a permis l'intégration de plus de 500 projets open source importants dans le programme de fuzzing-test continu. Suite aux vérifications effectuées, plus de 6 500 vulnérabilités vérifiées ont été corrigées et plus de 21 000 erreurs ont été résolues. ClusterFuzzLite continue de développer des mécanismes de tests de fuzzing avec la possibilité d'identifier plus tôt les problèmes lors de la révision des modifications proposées. ClusterFuzzLite a déjà été intégré aux processus de révision des modifications dans les projets systemd et curl, permettant de déceler des erreurs non repérées par les analyseurs statiques et les linter utilisés au début de la vérification du nouveau code.
ClusterFuzzLite prend en charge la vérification de projets dans les langages C, C++, Java (et d'autres langages basés sur la JVM), Go, Python, Rust et Swift. Les tests de fuzzing sont réalisés avec le moteur LibFuzzer. Pour détecter les erreurs liées à la mémoire et les anomalies, il est également possible d'appeler les outils AddressSanitizer, MemorySanitizer et UBSan (UndefinedBehaviorSanitizer).
Les principales fonctionnalités de ClusterFuzzLite : vérification rapide des modifications proposées pour trouver des erreurs avant l'acceptation du code ; téléchargement de rapports sur les conditions entraînant des plantages ; possibilité de passer à des tests de fuzzing plus approfondis pour identifier des erreurs plus profondes, non remontées lors de la vérification des modifications du code ; génération de rapports de couverture pour évaluer la couverture du code lors des tests ; architecture modulaire permettant de choisir les fonctionnalités nécessaires.
Rappelons qu'au cours des tests de fuzzing, un flux de combinaisons aléatoires de données d'entrée, se rapprochant 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 en-têtes anormaux, etc.), est généré et les éventuels échecs lors de leur traitement sont enregistrés. Si une certaine séquence provoque un plantage ou ne correspond pas à la réponse attendue, ce comportement indique très probablement une erreur ou une vulnérabilité.
Source : opennet.ru
