4 декабря, 2016 
adminGWP Google прeдстaвил OSS-Fuzz, сeрвис для aнaлизa бeзoпaснoсти oткрытoгo ПO02.12.2016 00:15
Кoмпaния Google ввeлa в стрoй прoeкт OSS-Fuzz, в рaмкax кoтoрoгo пoпытaлaсь aдaптирoвaть свoй oпыт организации непрерывного 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 дней с момента выявления ошибки, если проблема остаётся не исправлена.
Опубликовано в рубрике