Google heeft het ClusterFuzzLite-project gepresenteerd, waarmee fuzzing-testen van code kan worden georganiseerd voor een vroegtijdige identificatie van potentiƫle kwetsbaarheden tijdens het voortgangsproces van continue integratie. Momenteel kan ClusterFuzz worden gebruikt voor de automatisering van fuzzing-testen van pull-requests in GitHub Actions, Google Cloud Build en Prow, maar in de toekomst wordt er ondersteuning voor andere CI-systemen verwacht. Het project is gebaseerd op het ClusterFuzz-platform, dat is ontwikkeld voor de coƶrdinatie van de werking van clusters voor fuzzing-testen, en wordt verspreid onder de Apache 2.0-licentie.
Het wordt opgemerkt dat, na de implementatie in 2016 van de OSS-Fuzz-dienst door Google, meer dan 500 belangrijke open source-projecten in het continue fuzzing-testprogramma zijn opgenomen. Op basis van de uitgevoerde controles zijn meer dan 6500 bevestigde kwetsbaarheden verwijderd en zijn er meer dan 21.000 fouten opgelost. ClusterFuzzLite blijft de mechanismen voor fuzzing-testen ontwikkelen met de mogelijkheid om problemen eerder op te sporen tijdens de beoordelingsfase van voorgestelde wijzigingen. ClusterFuzzLite is al geĆÆmplementeerd in de beoordelingsprocessen van wijzigingen in de systemd- en curl-projecten, en heeft geholpen bij het identificeren van fouten die over het hoofd zijn gezien door statische analyzers en linters die in de beginfase van de controle van nieuw geschreven code zijn toegepast.
ClusterFuzzLite ondersteunt de controle van projecten in C, C++, Java (en andere JVM-gebaseerde talen), Go, Python, Rust en Swift. Fuzzing-testen worden uitgevoerd met behulp van de LibFuzzer-engine. Voor het opsporen van geheugenfouten en anomalieƫn kunnen ook tools zoals AddressSanitizer, MemorySanitizer en UBSan (UndefinedBehaviorSanitizer) worden aangeroepen.
De belangrijkste mogelijkheden van ClusterFuzzLite zijn: snelle controle van voorgestelde wijzigingen om fouten op te sporen voordat de code wordt goedgekeurd; uploaden van rapporten over het ontstaan van crashes; de mogelijkheid om over te schakelen naar meer geavanceerd fuzzing-testen om diepere fouten te identificeren die niet zijn blootgelegd na de controle van de wijziging van de code; genereren van coverage-rapporten om de codecoverage tijdens het testen te evalueren; modulaire architectuur die het mogelijk maakt om de benodigde functionaliteit te selecteren.
Laten we herinneren dat bij fuzzing-tests een stroom van willekeurige combinaties van invoerdata wordt gegenereerd, dicht bij echte data (zoals html-pagina's met willekeurige tagparameters, archieven of afbeeldingen met ongewone headers, enzovoort), en dat mogelijke fouten tijdens hun verwerking worden geregistreerd. Als een bepaalde reeks leidt tot een crash of niet voldoet aan de verwachte reactie, dan duidt dit met hoge waarschijnlijkheid op een fout of kwetsbaarheid.
Bron: opennet.ru
