L'infrastructure de test de fuzzing continu OSS-Fuzz a été enrichie d'une fonctionnalité permettant de tester des projets écrits en Lua, en plus des langages précédemment pris en charge tels que C/C++, Go, Swift, Rust, Python, JavaScript et Java. L'intégration a été réalisée via le projet luzer, qui développe des outils spécialisés pour le fuzzing du code Lua et des extensions Lua écrites en C/C++.
Le projet utilise la bibliothèque libFuzzer et peut être utilisé en conjonction avec les outils AddressSanitizer, MemorySanitizer, LeakSanitizer, ThreadSanitizer et Undefined Behavior Sanitizer, qui permettent, sur la base des problèmes identifiés pendant le fuzzing, de déterminer la présence de vulnérabilités typiques causées par des débordements de tampon, des débordements d'entiers, des accès à des zones non initialisées ou libérées, des fuites de mémoire, des déréférencements de pointeurs et des problèmes de verrouillage. Le code du projet est disponible sous licence ISC.
Dans le cadre de ses opérations, luzer teste toutes les combinaisons possibles d'entrées et génère un rapport sur tous les plantages détectés et les exceptions non interceptées. Par exemple, lors de l'examen de la bibliothèque de format MsgPack antirez/lua-cmsgpack avec luzer, il a été constaté que les données contenant un grand nombre de tableaux peuvent entraîner un débordement de pile.
Dans le cadre du projet lunapark, l'outil luzer est utilisé pour tester PUC Rio Lua, un compilateur traceur LuaJIT, une base de données à haute performance et de serveurs des applications Tarantool, ainsi que pour tester des modules Lua tiers.
Les développeurs de projets open source peuvent ajouter leurs référentiels pour les tests en préparant un modèle de fuzzing et en soumettant une demande spéciale via une pull request. Lors de la découverte d'erreurs, les développeurs reçoivent automatiquement une notification et une demande de correction privée est créée (pour éviter toute fuite prématurée d'informations sur les vulnérabilités, le ticket est créé dans le système de suivi des erreurs avec un accès restreint). OSS-Fuzz suit l'état de la correction de l'erreur et ferme automatiquement le ticket une fois qu'il n'est plus reproductible. Les informations sur le problème deviennent publiques après 7 jours suivant la correction ou après 90 jours depuis la détection de l'erreur, si la problématique reste non corrigée.
Source : opennet.ru
