Google представил OSS-Fuzz, сервис для анализа безопасности открытого ПО
Компания Google ввела в строй проект OSS-Fuzz, в рамках которого попыталась адаптировать свой опыт организации непрерывного fuzzing-тестирования Chromium для обеспечения тестирования любых открытых проектов. Суть fuzzing-тестирования в генерации потока всевозможных случайных комбинаций входных данных, приближенных к реальным данным (например, html-страницы с случайными параметрами тегов или изображения с аномальными заголовками), и фиксации возможных сбоев в процессе их обработки. Если какая-то последовательность приводит к краху или не соответствует ожидаемой реакции, то такое поведение с высокой вероятностью свидетельствует об ошибке или уязвимости.
Первый вариант сервиса основан на применении движка libFuzzer, ранее переданного сообществу LLVM, и набора Google Sanitizers, в которых входят инструменты AddressSanitizer, MemorySanitizer,LeakSanitizer и ThreadSanitizer, позволяющие выявлять типовые проблемы с адресацией, обращением к неинициализированным областям, утечками памяти и проблемами с установкой блокировок. В будущем в OSS-Fuzz планируется обеспечить поддержку и других движков fuzzing-тестирования. Для формирования отчетов и распределенного тестирования кода задействован кластер ClusterFuzz, уже применяемый для проверки Chrome.
В настоящее время в OSS-Fuzz уже обеспечивает около 4 триллионов проверок в неделю. Тестирование охватывает 31 открытый проект, среди которых SQLite, PCRE2, openssl, boringssl, coreutils, curl, ffmpeg, freetype2, libjpeg-turbo, libpng, node.js, nss, pidgin и zlib. Проверка данных проектов уже выявила 150 ошибок.
Разработчики других открытых проектов могут добавить свои репозитории для тестирования, подготовив шаблон fuzzing-тестирования и отправив специальную заявку через pull-запрос. При обнаружении ошибок, разработчикам автоматически отправляется уведомление и создается приватная заявка на исправление (чтобы исключить преждевременной утечки сведений об уязвимостях, issue создается в системе отслеживания ошибок с ограниченным доступом). ClusterFuzz отслеживает состояние исправления ошибки и сам закрывает issue. Информация о проблеме становится публично доступной спустя 7 дней после исправления или спустя 90 дней с момента выявления ошибки, если проблема остается не исправлена.
