Nell'infrastruttura per il fuzz testing continuo di OSS-Fuzz è stata aggiunta la possibilità di testare progetti scritti in linguaggio Lua, oltre ai linguaggi già supportati come C/C++, Go, Swift, Rust, Python, JavaScript e Java. L'integrazione è stata realizzata tramite il progetto luzer, che sviluppa strumenti specializzati per il fuzz testing del codice in Lua e delle estensioni Lua scritte in C/C++.
Il progetto utilizza la libreria libFuzzer e può essere utilizzato insieme agli strumenti AddressSanitizer, MemorySanitizer, LeakSanitizer, ThreadSanitizer e Undefined Behavior Sanitizer, che consentono di rilevare problemi durante il fuzz testing e identificare la presenza di vulnerabilità comuni causate da buffer overflow, overflow interi, accesso a aree non inizializzate o liberate, perdite di memoria, dereferenziazione di puntatori e problemi di locking. Il codice del progetto è disponibile con licenza ISC.
Durante il funzionamento, luzer esplora possibili combinazioni di dati in ingresso e genera un rapporto su tutti i malfunzionamenti e le eccezioni non gestite individuate. Ad esempio, durante il controllo della libreria MsgPack antirez/lua-cmsgpack su luzer, è stato rilevato che i dati con un gran numero di array possono causare un overflow dello stack.
Nel progetto lunapark, lo strumento luzer è utilizzato per testare PUC Rio Lua, il compilatore JIT LuaJIT, un sistema di gestione di database ad alte prestazioni e server applicazioni Tarantool, oltre a testare moduli Lua di terze parti.
Gli sviluppatori di progetti open source possono aggiungere i loro repository per il testing, preparando un modello di test di fuzzing e inviando una richiesta speciale tramite pull request. In caso di rilevamento di errori, agli sviluppatori viene automaticamente inviato un avviso e viene creata una richiesta privata di correzione (per evitare fughe premature di informazioni sulle vulnerabilità, il ticket viene creato nel sistema di tracciamento degli errori con accesso limitato). OSS Fuzz monitora lo stato della correzione dell'errore e chiude il ticket automaticamente se l'errore non si verifica più. Le informazioni sul problema diventano pubblicamente disponibili dopo 7 giorni dalla correzione o dopo 90 giorni dalla scoperta dell'errore, se il problema rimane irrisolto.
Fonte: opennet.ru
