В инфраструктурата OSS Fuzz е реализирана поддръжка на проекти на езика Lua

В инфраструктурата за непрекъснато фаззинг-тестиране OSS-Fuzz е добавена възможност за тестване на проекти, написани на езика Lua, в допълнение към преди това поддържаните езици C/C++, Go, Swift, Rust, Python, JavaScript и Java. Интеграцията е реализирана с помощта на проекта luzer, който разработва специализиран инструментариум за фаззинг-тестиране на код на езика Lua и разширения за Lua, написани на C/C++.

Проектът използва библиотеката libFuzzer и може да се прилага съвместно с инструментите AddressSanitizer, MemorySanitizer, LeakSanitizer, ThreadSanitizer и Undefined Behavior Sanitizer, които позволяват на база установените по време на фаззинг-тестиране проблеми да се определят типични уязвимости, причинени от препълвания на буфера, целочислени препълвания, достъп до неинициализирани и освобождаеми области, изтичане на памет, разименуване на указатели и проблеми с блокировките. Кодът на проекта е достъпен под лицензия ISC.

В процеса на работа luzer извършва комбинации на входящите данни и генерира доклад за всички установени сблъсъци и неперехванати изключения. Например, при проверка в luzer на библиотеката за парсинг на формата MsgPack antirez/lua-cmsgpack беше установено, че данни с голямо количество масиви могат да доведат до препълване на стека.

В рамките на проекта lunapark инструментариумът luzer се използва за тестване на PUC Rio Lua, трасировъчния компилатор LuaJIT, високопроизводителната СУБД и сървър приложенията Tarantool, както и за тестване на странични Lua-модули.

Разработчиците на отворени проекти могат да добавят своите репозитории за тестване, подготвяйки шаблон за фаззинг-тестиране и изпращайки специална заявка чрез pull-запитване. При откритие на грешки, разработчиците автоматично получават уведомление и се създава частна заявка за корекция (за да се изключи преждевременната информация за уязвимостите, тикетът се създава в системата за управление на грешки с ограничен достъп). OSS Fuzz проследява състоянието на корекцията на грешката и сам затваря тикета, ако той вече не се възпроизвежда. Информацията за проблема става публично достъпна след 7 дни след корекцията или след 90 дни от момента на откритие на грешката, ако проблемът остава некоригиран.

Източник: opennet.ru