В инфраструктурата за непрекъснато фаззинг-тестиране 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
