Google ha presentato il progetto ClusterFuzzLite, che consente di organizzare il fuzzing del codice per rilevare precocemente potenziali vulnerabilità durante il funzionamento dei sistemi di integrazione continua. Attualmente, ClusterFuzz può essere utilizzato per automatizzare il fuzzing delle pull request in GitHub Actions, in Google Cloud Build e in Prow, ma si prevede in futuro il supporto per altri sistemi CI. Il progetto è basato sulla piattaforma ClusterFuzz, creata per coordinare il lavoro dei cluster di fuzzing e distribuito con licenza Apache 2.0.
Si segnala che dopo l'introduzione nel 2016 da parte di Google del servizio OSS-Fuzz nel programma di fuzzing testing continuo, sono stati accolti oltre 500 importanti progetti open source. Sulla base delle verifiche effettuate, sono state eliminate più di 6500 vulnerabilità confermate e corrette oltre 21.000 errori. ClusterFuzzLite continua a sviluppare meccanismi di fuzzing testing con la possibilità di identificare prima i problemi nella fase di revisione delle modifiche proposte. ClusterFuzzLite è già stato implementato nei processi di revisione delle modifiche nei progetti systemd e curl, e ha permesso di individuare errori trascurati da analizzatori statici e linter utilizzati nelle fasi iniziali di verifica del nuovo codice.
ClusterFuzzLite supporta il controllo dei progetti in linguaggi come C, C++, Java (e altri linguaggi basati su JVM), Go, Python, Rust e Swift. Il fuzzing testing viene realizzato utilizzando il motore LibFuzzer. Per l'individuazione degli errori di gestione della memoria e delle anomalie possono anche essere attivati strumenti come AddressSanitizer, MemorySanitizer e UBSan (UndefinedBehaviorSanitizer).
Le principali funzionalità di ClusterFuzzLite includono: verifica rapida delle modifiche proposte per individuare errori prima dell'accettazione del codice; caricamento di report sulle condizioni di crash; possibilità di passare a una fuzzing-test più approfondita per identificare errori più gravi non emersi dopo la revisione del codice; generazione di report di copertura per valutare l'ambito del codice durante il testing; architettura modulare che consente di selezionare le funzionalità necessarie.
Ricordiamo che durante il fuzzing-test viene generato un flusso di varie combinazioni casuali di dati d'ingresso, simili ai dati reali (ad esempio, pagine HTML con parametri casuali nei tag, archivi o immagini con intestazioni anomale, ecc.), e viene registrato eventuali malfunzionamenti nel loro trattamento. Se una certa sequenza provoca un crash o non corrisponde alla reazione attesa, tale comportamento è altamente indicativo di un errore o vulnerabilità.
Fonte: opennet.ru
