Google har presenterat fuzzing-testningssystemet ClusterFuzzLite.

Google har presenterat projektet ClusterFuzzLite, som möjliggör fuzzing-testning av kod för tidig upptäckte av potentiella sårbarheter under arbetet med kontinuerlig integrationssystem. För närvarande kan ClusterFuzz användas för automatisering av fuzzing-testning av pull-förfrågningar i GitHub Actions, Google Cloud Build och Prow, men stöd för andra CI-system förväntas inom en snar framtid. Projektet är baserat på plattformen ClusterFuzz, som har skapats för att samordna arbetet med fuzzing-testningskluster och sprids under Apache 2.0-licensen.

Det noteras att efter att Google införde tjänsten OSS-Fuzz 2016 har mer än 500 viktiga öppna projekt inkluderats i programmet för kontinuerlig fuzzing-testning. Baserat på utförda kontroller har över 6500 bekräftade sårbarheter åtgärdats och mer än 21 000 fel har korrigerats. ClusterFuzzLite fortsätter att utveckla mekanismer för fuzzing-testning med möjligheten att tidigare upptäcka problem i granskningen av föreslagna ändringar. ClusterFuzzLite har redan implementerats i granskningsprocesser för ändringar i projekten systemd och curl och har möjliggjort att upptäcka fel som har missats av statiska analyserare och linters som användes i det tidiga skedet av kontrollen av ny kod.

ClusterFuzzLite stödjer kontroll av projekt på språken C, C++, Java (och andra språk baserade på JVM), Go, Python, Rust och Swift. Fuzzing-testning genomförs med hjälp av motorn LibFuzzer. För att identifiera minnesfel och anomalier kan även verktygen AddressSanitizer, MemorySanitizer och UBSan (UndefinedBehaviorSanitizer) anropas.

Huvudfunktionerna i ClusterFuzzLite: snabb kontroll av föreslagna ändringar för att hitta fel innan kod godkänns; uppladdning av rapporter om kraschar; möjlighet att övergå till mer omfattande fuzzing-testning för att upptäcka djupare fel som inte framkommit efter granskning av kodändringar; generering av coverage-rapporter för att bedöma kodtäckningen vid testning; modulär arkitektur som tillåter val av nödvändig funktionalitet.

Vi påminner om att fuzzing-testning innebär att generera en ström av alla möjliga slumpmässiga kombinationer av indata som liknar verkliga data (till exempel html-sidor med slumpmässiga taggparametrar, arkiv eller bilder med avvikande rubriker osv.), och att registrera eventuella krasch under bearbetningen av dessa. Om en viss sekvens leder till ett krasch eller inte ger den förväntade reaktionen, så tyder detta med stor sannolikhet på ett fel eller en sårbarhet.

Källa: opennet.ru