Compania Google a prezentat proiectul ClusterFuzzLite, care facilitează testarea fuzzing a codului pentru identificarea timpurie a potențialelor vulnerabilități în etapele de lucru ale sistemelor de integrare continuă. În prezent, ClusterFuzz poate fi utilizat pentru automatizarea testării fuzzing a pull request-urilor în GitHub Actions, Google Cloud Build și Prow, dar se așteaptă să existe și suport pentru alte sisteme CI în viitor. Proiectul se bazează pe platforma ClusterFuzz, creată pentru coordonarea activității clusterelor de testare fuzzing și este distribuit sub licența Apache 2.0.
Se observă că, după implementarea în 2016 de către compania Google a serviciului OSS-Fuzz, mai mult de 500 de proiecte open source importante au fost acceptate în programul de testare fuzzing continuă. Pe baza verificărilor efectuate, au fost eliminate mai mult de 6500 de vulnerabilități confirmate și au fost corectate peste 21.000 de erori. ClusterFuzzLite continuă dezvoltarea mecanismelor de testare fuzzing, având capacitatea de a identifica mai devreme problemele în etapa de revizuire a modificărilor propuse. ClusterFuzzLite este deja implementat în procesele de revizuire a modificărilor în proiectele systemd și curl, permițând identificarea erorilor omise de analizoarele statice și linte-urile utilizate în etapa inițială de verificare a noului cod.
ClusterFuzzLite suportă verificarea proiectelor în limbajele C, C++, Java (și alte limbaje bazate pe JVM), Go, Python, Rust și Swift. Testarea fuzzing se desfășoară utilizând motorul LibFuzzer. Pentru identificarea erorilor legate de gestionarea memoriei și a anomaliilor, pot fi apelate de asemenea instrumentele AddressSanitizer, MemorySanitizer și UBSan (UndefinedBehaviorSanitizer).
Principalele caracteristici ale ClusterFuzzLite: verificarea rapidă a modificărilor propuse pentru identificarea erorilor înainte de acceptarea codului; încărcarea rapoartelor despre condițiile care cauzează crash-uri; posibilitatea de a trece la un testare fuzzing mai extinsă pentru identificarea unor erori mai profunde, care nu au fost detectate după verificarea modificării codului; generarea de rapoarte de acoperire pentru evaluarea acoperirii codului în timpul testării; arhitectura modulară, care permite selectarea funcționalităților necesare.
Reamintim că în testarea fuzzing se generează un flux de diverse combinații aleatorii ale datelor de intrare, apropiate de datele reale (de exemplu, pagini html cu parametrii aleatori ai etichetelor, arhive sau imagini cu antete anormale etc.), și se înregistrează eventualele erori în procesul de procesare. Dacă o anumită secvență duce la o blocare sau nu corespunde reacției așteptate, un astfel de comportament indică cu o mare probabilitate o eroare sau o vulnerabilitate.
Sursa: opennet.ro
