Google представи системата за fuzzing тестиране ClusterFuzzLite

Компания Google представи проект ClusterFuzzLite, позволяващ организирането на fuzzing-тестове на кода за ранно откриване на потенциални уязвимости по време на работа на системи за непрекъсната интеграция. В момента ClusterFuzz може да се използва за автоматизация на fuzzing-тестовете на pull-заявки в GitHub Actions, Google Cloud Build и Prow, но в бъдеще се предвижда добавяне на поддръжка и за другите CI-системи. Проектът се базира на платформата ClusterFuzz, създадена за координация на работата на клъстери за fuzzing-тестове и се разпространява под лицензия Apache 2.0.

Отбелязва се, че след внедряването през 2016 година на услугата OSS-Fuzz от Google в програмата за непрекъснато fuzzing-тестиране, са приети над 500 важни отворени проекта. На базата на проведените проверки бяха отстранени над 6500 потвърдени уязвимости и коригирани повече от 21 хиляди грешки. ClusterFuzzLite продължава да развива механизми за fuzzing-тестиране с възможността за по-скорошно откриване на проблеми на етапа на преглед на предложените промени. ClusterFuzzLite вече е внедрен в процесите на преглед на промените в проектите systemd и curl и позволи откриването на грешки, пропуснати от статичните анализатори и линтерите, приложени на началния етап на проверка на новия код.

ClusterFuzzLite поддържа проверка на проекти на езици C, C++, Java (и други езици на базата на JVM), Go, Python, Rust и Swift. Fuzzing-тестовете се провеждат с използване на движка LibFuzzer. За откриване на грешки в работата с паметта и аномалии също могат да се извикват инструменти AddressSanitizer, MemorySanitizer и UBSan (UndefinedBehaviorSanitizer).

Основни възможности на ClusterFuzzLite: бърза проверка на предложените промени за намиране на грешки на етапа преди приемане на кода; качване на доклади за условията на възникване на сривове; възможност за преминаване към по-разширено fuzzing-тестиране за откриване на по-дълбоки грешки, които не са изплували след проверка на промяната на кода; генериране на coverage-доклади за оценка на покритостта на кода при тестване; модулна архитектура, позволяваща избор на необходимата функционалност.

Напомняме, че при fuzzing-тестове се генерират потоци от произволни комбинации на входни данни, приближаващи се до реални данни (например, html-страници с произволни параметри на таговете, архиви или изображения с аномални заглавия и т.н.), и се регистрират възможни сривове по време на тяхната обработка. Ако някоя последователност води до срив или не съответства на очакваната реакция, такова поведение с висока вероятност показва грешка или уязвимост.

Източник: opennet.ru