Google heeft het ClusterFuzzLite-project geïntroduceerd, waarmee u fuzzingtests van code kunt organiseren voor vroege detectie van potentiële kwetsbaarheden in de fase van continue integratiesystemen. Momenteel kan ClusterFuzz worden gebruikt om fuzzingtests van pull-requests in GitHub Actions, Google Cloud Build en Prow te automatiseren, maar ondersteuning voor andere CI-systemen wordt in de toekomst verwacht. Het project is gebaseerd op het ClusterFuzz-platform, ontwikkeld om het werk van fuzzingtestclusters te coördineren, en wordt gedistribueerd onder de Apache 2.0-licentie.
Na de introductie van de OSS-Fuzz-service door Google in 2016 zijn meer dan 500 belangrijke open-sourceprojecten toegelaten tot het continue fuzzing-testprogramma. Op basis van de uitgevoerde controles zijn meer dan 6500 bevestigde kwetsbaarheden geëlimineerd en meer dan 21 fouten hersteld. ClusterFuzzLite blijft fuzzing-testmechanismen ontwikkelen die problemen al in een eerder stadium van de beoordeling van voorgestelde wijzigingen kunnen detecteren. ClusterFuzzLite is al geïmplementeerd in de beoordelingsprocessen van wijzigingen in de systemd- en curl-projecten en heeft het mogelijk gemaakt om fouten te identificeren die niet zijn gedetecteerd door statische analyzers en linters die in de beginfase van de controle van nieuwe code worden gebruikt.
ClusterFuzzLite ondersteunt het controleren van projecten in C, C++, Java (en andere JVM-gebaseerde talen), Go, Python, Rust en Swift. Fuzzingtests worden uitgevoerd met de LibFuzzer-engine. De tools AddressSanitizer, MemorySanitizer en UBSan (UndefinedBehaviorSanitizer) kunnen ook worden aangeroepen om geheugenfouten en -afwijkingen te detecteren.
Belangrijkste kenmerken van ClusterFuzzLite: snel testen van voorgestelde wijzigingen om fouten te vinden voordat de code wordt geaccepteerd; rapporten laden over crashomstandigheden; de mogelijkheid om over te stappen op geavanceerdere fuzzing-testen om dieperliggende fouten te identificeren die niet aan het licht kwamen na controle van de codewijziging; genereren van dekkingsrapporten om de codedekking tijdens het testen te beoordelen; modulaire architectuur waarmee u de benodigde functionaliteit kunt kiezen.
Laten we niet vergeten dat fuzzingtesten bestaan uit het genereren van een stroom van allerlei willekeurige combinaties van invoergegevens die dicht bij de echte gegevens liggen (bijvoorbeeld HTML-pagina's met willekeurige tagparameters, archieven of afbeeldingen met afwijkende headers, enz.) en het vastleggen van mogelijke fouten tijdens de verwerking ervan. Als een sequentie faalt of niet reageert zoals verwacht, dan is de kans groot dat het om een bug of kwetsbaarheid gaat.
Bron: opennet.ru
