W infrastrukturze ciągłego testowania fuzzingowego OSS-Fuzz dodano możliwość testowania projektów napisanych w języku Lua, obok wcześniej wspieranych języków C/C++, Go, Swift, Rust, Python, JavaScript i Java. Integracja została zrealizowana dzięki projektowi luzer, który rozwija specjalistyczne narzędzia do testowania fuzzingowego kodu w języku Lua oraz rozszerzeń do Lua, napisanych w C/C++.
Projekt wykorzystuje bibliotekę libFuzzer i może być używany razem z narzędziami AddressSanitizer, MemorySanitizer, LeakSanitizer, ThreadSanitizer i Undefined Behavior Sanitizer, które na podstawie wykrytych podczas testowania fuzzingowego problemów, pozwalają określić obecność typowych luk bezpieczeństwa spowodowanych przepełnieniem bufora, przepełnieniem liczb całkowitych, odwołaniami do nieinicjowanych i zwolnionych obszarów, wyciekami pamięci, dereferencją wskaźników i problemami z blokowaniem. Kod projektu jest dostępny na licencji ISC.
Podczas pracy luzer przeszukuje możliwe kombinacje danych wejściowych i generuje raport o wszystkich wykrytych awariach i nieprzechwyconych wyjątkach. Na przykład, podczas testowania w luzer biblioteki analizującej format MsgPack antirez/lua-cmsgpack wykazano, że dane z dużą liczbą tablic mogą prowadzić do przepełnienia stosu.
W ramach projektu lunapark narzędzie luzer jest stosowane do testowania PUC Rio Lua, kompilatora śledzącego LuaJIT, wysokowydajnej bazy danych oraz serwera aplikacji Tarantool, a także do testowania zewnętrznych modułów Lua.
Deweloperzy otwartych projektów mogą dodać swoje repozytoria do testowania, przygotowując szablon testowania fuzzingowego i wysyłając specjalny wniosek przez pull request. W przypadku wykrycia błędów deweloperzy automatycznie otrzymują powiadomienie, a prywatny wniosek o naprawę jest tworzony (aby uniknąć przedwczesnego wycieku informacji o lukach, zgłoszenie jest tworzone w systemie śledzenia błędów z ograniczonym dostępem). OSS Fuzz śledzi status naprawy błędu i automatycznie zamyka zgłoszenie, jeśli przestaje się powtarzać. Informacje o problemie stają się publicznie dostępne po 7 dniach od naprawy lub po 90 dniach od momentu wykrycia błędu, jeśli problem pozostaje nienaprawiony.
Źródło: opennet.ru
