Компания Google ввела в строй проект OSS-Fuzz, в рамках которого попыталась адаптировать свой опыт организации непрерывного fuzzing-тестирования Chromium для обеспечения тестирования любых открытых проектов. Суть fuzzing-тестирования в генерации потока всевозможных случайных комбинаций входных данных, приближенных к реальным данным (например, html-страницы с случайными параметрами тегов или изображения с аномальными заголовками), и фиксации возможных сбоев в процессе их обработки. Если какая-то последовательность приводит к краху или не соответствует ожидаемой реакции, то такое поведение с высокой вероятностью свидетельствует об ошибке или уязвимости.

Первый вариант сервиса основан на применении движка libFuzzer, ранее переданного сообществу LLVM, и набора Google Sanitizers, в который входят инструменты AddressSanitizer, MemorySanitizer, LeakSanitizer и ThreadSanitizer, позволяющие на основе выявленных в процессе fuzzing-тестирования проблем, определять наличие типовых уязвимостей, вызванных переполнениями буфера, целочисленными переполнениями, обращением к неинициализированным и освобождённым областям, утечками памяти, разыменованием указателей и проблемами с установкой блокировок.

В будущем в OSS-Fuzz планируется обеспечить поддержку и других движков fuzzing-тестирования, таких как AFL. Для формирования отчётов и распределённого тестирования кода задействован кластер ClusterFuzz, уже применяемый для проверки Chrome. В настоящее время в OSS-Fuzz обеспечивает около 4 триллионов проверок в неделю. Тестирование охватывает 31 открытый проект, среди которых SQLite, PCRE2, openssl, boringssl, coreutils, curl, ffmpeg, freetype2, libjpeg-turbo, libpng, node.js, nss, pidgin и zlib. В процессе проверки данных проектов выявлено 150 ошибок, из которых 92 ошибки уже исправлены.

Разработчики других открытых проектов могут добавить свои репозитории для тестирования, подготовив шаблон fuzzing-тестирования и отправив специальную заявку через pull-запрос. При обнаружении ошибок, разработчикам автоматически отправляется уведомление и создаётся приватная заявка на исправление (чтобы исключить преждевременной утечки сведений об уязвимостях, issue создаётся в системе отслеживания ошибок с ограниченным доступом). ClusterFuzz отслеживает состояние исправления ошибки и сам закрывает issue. Информация о проблеме становится публично доступной спустя 7 дней после исправления или спустя 90 дней с момента выявления ошибки, если проблема остаётся не исправленной.

Источник: http://www.opennet.ru/opennews/art.shtml?num=45602