Le framework de tests de fuzzing continu OSS-Fuzz prend désormais en charge les projets écrits en Lua, en plus des langages déjà compatibles : C/C++, Go, Swift, Rust, Python, JavaScript et Java. Cette intégration a été réalisée grâce au projet luzer, qui développe des outils spécialisés pour le fuzzing du code Lua et des extensions Lua écrites en C/C++.
Ce projet utilise la bibliothèque libFuzzer et peut être utilisé conjointement avec AddressSanitizer, MemorySanitizer, LeakSanitizer, ThreadSanitizer et Undefined Behavior Sanitizer, qui exploitent le fuzzing pour identifier les vulnérabilités courantes telles que les dépassements de tampon, les dépassements d'entiers, les accès à des zones non initialisées ou libérées, les fuites de mémoire, les déréférencements de pointeurs et les problèmes de verrouillage. Le code source du projet est disponible sous licence ISC.
Lors de son exécution, Luzer parcourt les combinaisons possibles de données d'entrée et génère un rapport de toutes les erreurs détectées et des exceptions non gérées. Par exemple, lors des tests de la bibliothèque d'analyse syntaxique MsgPack antirez/lua-cmsgpack avec Luzer, il a été constaté que des données contenant un grand nombre de tableaux pouvaient provoquer un dépassement de capacité de la pile.
Le projet Lunapark utilise la boîte à outils Luzer pour tester le PUC de Rio Lua, le compilateur de traçage LuaJIT, un SGBD haute performance, et serveur Applications Tarantool, ainsi que pour tester des modules Lua tiers.
Les développeurs open source peuvent ajouter leurs dépôts aux tests en préparant un modèle de test de fuzzing et en soumettant une demande de fusion. Lorsqu'un bogue est découvert, les développeurs sont automatiquement notifiés et un ticket de correction privé est créé (afin d'éviter toute divulgation prématurée de la vulnérabilité, le ticket est créé dans un système de suivi des bogues à accès restreint). OSS Fuzz surveille l'état de la correction du bogue et ferme automatiquement le ticket si le bogue n'est plus reproductible. Les informations relatives au problème sont rendues publiques sept jours après la publication du correctif, ou 90 jours après la découverte du bogue si le problème persiste.
Source: opennet.ru
