Firma Google przedstawiła projekt ClusterFuzzLite, który umożliwia organizację testów fuzzingowych kodu w celu wczesnego wykrywania potencjalnych luk bezpieczeństwa na etapie działania systemów ciągłej integracji. Obecnie ClusterFuzz może być używany do automatyzacji testów fuzzingowych pull requestów w GitHub Actions, Google Cloud Build i Prow, ale w przyszłości spodziewane jest wsparcie także dla innych systemów CI. Projekt opiera się na platformie ClusterFuzz, stworzonej do koordynacji pracy klastrów testów fuzzingowych, i jest rozpowszechniany na licencji Apache 2.0.
Zaznacza się, że po wprowadzeniu w 2016 roku przez firmę Google usługi OSS-Fuzz do programu ciągłego testowania fuzzingowego, przyjęto ponad 500 ważnych otwartych projektów. Na podstawie przeprowadzonych weryfikacji usunięto ponad 6500 potwierdzonych luk bezpieczeństwa i poprawiono ponad 21 tysięcy błędów. ClusterFuzzLite kontynuuje rozwój mechanizmów testów fuzzingowych z możliwością wcześniejszego wykrywania problemów na etapie recenzji proponowanych zmian. ClusterFuzzLite jest już wdrożony w procesach recenzji zmian w projektach systemd i curl, pozwalając na identyfikację błędów, które zostały pominięte przez statyczne analizatory i lintery stosowane na wczesnym etapie weryfikacji nowego kodu.
ClusterFuzzLite wspiera weryfikację projektów w językach C, C++, Java (i innych językach opartych na JVM), Go, Python, Rust i Swift. Testy fuzzingowe są wykonywane z użyciem silnika LibFuzzer. W celu wykrywania błędów pracy z pamięcią i anomalii można również wywołać narzędzia AddressSanitizer, MemorySanitizer i UBSan (UndefinedBehaviorSanitizer).
Główne możliwości ClusterFuzzLite: szybka weryfikacja proponowanych zmian w celu wykrycia błędów przed przyjęciem kodu; przesyłanie raportów o warunkach występowania awarii; możliwość przejścia do bardziej zaawansowanego testowania fuzzingowego w celu wykrycia głębszych błędów, które nie ujawniły się po weryfikacji zmiany kodu; generowanie raportów o pokryciu kodu podczas testowania; modułowa architektura, umożliwiająca wybór potrzebnej funkcjonalności.
Przypominamy, że podczas testowania fuzzing generuje się strumień wszelkich losowych kombinacji danych wejściowych, zbliżonych do rzeczywistych danych (na przykład, stron html z losowymi parametrami tagów, archiwów lub obrazów z anormalnymi nagłówkami itp.), a także rejestruje się ewentualne awarie w trakcie ich przetwarzania. Jeśli jakaś sekwencja prowadzi do awarii lub nie odpowiada oczekiwanej reakcji, to takie zachowanie z wysokim prawdopodobieństwem świadczy o błędzie lub podatności.
Źródło: opennet.ru
