Die Google LLC hat das Projekt ClusterFuzzLite vorgestellt, das die Durchführung von Fuzzing-Tests des Codes ermöglicht, um potenzielle Schwachstellen frühzeitig in der Phase der kontinuierlichen Integration zu identifizieren. Derzeit kann ClusterFuzz zur Automatisierung von Fuzzing-Tests von Pull-Requests in GitHub Actions, Google Cloud Build und Prow verwendet werden, in Zukunft wird jedoch auch die Unterstützung anderer CI-Systeme erwartet. Das Projekt basiert auf der ClusterFuzz-Plattform, die zur Koordination der Arbeit von Fuzzing-Test-Clustern entwickelt wurde und unter der Lizenz Apache 2.0 veröffentlicht wird.
Es wird festgestellt, dass seit der Einführung des OSS-Fuzz-Dienstes durch Google im Jahr 2016 über 500 wichtige Open-Source-Projekte in das Programm für kontinuierliche Fuzzing-Tests integriert wurden. Nach den durchgeführten Prüfungen wurden über 6500 bestätigte Schwachstellen behoben und mehr als 21.000 Fehler korrigiert. ClusterFuzzLite entwickelt weiterhin die Mechanismen des Fuzzing-Tests mit der Möglichkeit, Probleme früher in der Phase der Überprüfung vorgeschlagener Änderungen zu identifizieren. ClusterFuzzLite ist bereits in die Änderungsreview-Prozesse der Projekte systemd und curl integriert und hat es ermöglicht, Fehler zu erkennen, die von statischen Analysetools und Lintern, die in der frühen Phase der Codeüberprüfung verwendet wurden, übersehen wurden.
ClusterFuzzLite unterstützt die Überprüfung von Projekten in den Programmiersprachen C, C++, Java (und anderen Sprachen auf der JVM), Go, Python, Rust und Swift. Die Fuzzing-Tests werden unter Verwendung der LibFuzzer-Engine durchgeführt. Zur Erkennung von Fehlern im Umgang mit dem Speicher und Anomalien können auch die Werkzeuge AddressSanitizer, MemorySanitizer und UBSan (UndefinedBehaviorSanitizer) aufgerufen werden.
Die Hauptfunktionen von ClusterFuzzLite: schnelle Überprüfung der vorgeschlagenen Änderungen zur Fehlersuche vor der Annahme des Codes; das Hochladen von Berichten über Crash-Bedingungen; die Möglichkeit, zu umfangreicheren Fuzzing-Tests überzugehen, um tiefere Fehler zu identifizieren, die nach der Überprüfung des Codes nicht aufgetreten sind; die Generierung von Coverage-Berichten zur Bewertung der Codeabdeckung während der Tests; modulare Architektur, die es ermöglicht, die erforderliche Funktionalität auszuwählen.
Wir erinnern daran, dass beim Fuzzing-Testing eine Vielzahl von zufälligen Kombinationen von Eingabedaten generiert wird, die realen Daten ähnlich sind (zum Beispiel HTML-Seiten mit zufälligen Tag-Parametern, Archive oder Bilder mit anomalen Headern usw.), und dass mögliche Fehler während ihrer Verarbeitung erfasst werden. Wenn eine bestimmte Sequenz zu einem Absturz führt oder nicht der erwarteten Reaktion entspricht, weist dieses Verhalten mit hoher Wahrscheinlichkeit auf einen Fehler oder eine Schwachstelle hin.
Quelle: opennet.ru
