Fuzz testing

Современные фаззеры очень эффективны, и мы хотим использовать их, чтобы гарантировать, что в BoringSSL не закрадутся глупые ошибки.

Мы используем Clang libFuzzer для фаззинга, и в fuzz/ есть ряд функций для фаззингового тестирования. Они не собираются по умолчанию, потому что для этого требуется собрать остальную часть BoringSSL с некоторыми изменениями, которые делают фаззинг намного более эффективным, но совершенно небезопасны для реального использования.

Чтобы собрать фаззер-тесты, вам понадобится как минимум Clang 6.0. Передайте -DFUZZ=1 в командной строке CMake, чтобы включить сборку BoringSSL с покрытием и AddressSanitizer, а также сборку двоичных файлов для фаззер-теста. Вероятно, вам также потребуется установить переменные среды CC и CXX, например так:

mkdir build
cd build
CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 ..
ninja

Из каталога build/ вы можете затем запустить фаззеры. Например:

./fuzz/cert -max_len=10000 -jobs=32 -workers=32 ../fuzz/cert_corpus/

Аргументы для jobs и workers должны быть количеством ядер, которое вы хотите выделить для фаззинга. По умолчанию libFuzzer использует самый большой тест в корпусе (или 64, если он пуст) в качестве максимального размера тестового примера. Аргумент max_len переопределяет это.

Рекомендуемые значения max_len для каждого теста:

Они были определены путём округления до большего значения длины самого большого случая в корпусе.

В fuzz/ есть каталоги для каждого из фаззер-тестов, содержащие начальные файлы для фаззинга. Некоторые из начальных файлов были созданы вручную, но многие из них являются «интересными» результатами, полученными самим фаззингом. («Интересный» означает, что он активировал ранее неизвестный путь в коде.)

Минимизация корпусов

Когда доступно большое количество новых начальных файлов, рекомендуется минимизировать корпус, чтобы можно было дедуплицировать разные начальные файлы, запускающие одни и те же пути кода.

Для минимизации всех корпусов соберите для фаззинга и запустите ./fuzz/minimise_corpuses.sh. Обратите внимание, что минимизация часто не является идемпотентной по неизвестным причинам.

Режим фаззера

При передаче -DFUZZ=1 в CMake BoringSSL собирается с BORINGSSL_UNSAFE_FUZZER_MODE и BORINGSSL_UNSAFE_DETERMINISTIC_MODE, определёнными. Это изменяет библиотеку, делая её более дружественной к фаззерам. Если установлен BORINGSSL_UNSAFE_DETERMINISTIC_MODE, BoringSSL будет:

• Заменять RAND_bytes детерминированным PRNG. Вызывать RAND_reset_for_fuzzing() в начале фаззеров, использующих RAND_bytes, для сброса состояния PRNG.
• Использовать жёстко заданное время вместо фактического времени.

Кроме того, если установлен BORINGSSL_UNSAFE_FUZZER_MODE, BoringSSL будет:

• Изменять стек TLS для выполнения всех проверок подписи (CertificateVerify и ServerKeyExchange) и проверки Finished, но всегда действовать так, как будто проверка прошла успешно.
• Обрабатывать каждый шифр как нулевой шифр.
• Билеты не зашифрованы, и проверка MAC выполняется, но игнорируется.
• Проверки renegotiation_info игнорируются.

Это делается для предотвращения застревания фаззера на криптографическом инварианте в протоколе.

TLS-транскрипты

Корпуса client и server заполняются начальными данными из набора тестов. В наборе тестов есть флаг -fuzzer, который отражает изменения режима фаззера выше, и флаг -deterministic, который удаляет весь недетерминизм на стороне Go. Не все тесты проходят, поэтому ssl/test/runner/fuzzer_mode.json содержит необходимые подавления. Цель run_tests передаст соответствующие флаги командной строки.

Существуют отдельные корпуса client_corpus_no_fuzzer_mode и server_corpus_no_fuzzer_mode. Это транскрипты для фаззеров только с BORINGSSL_UNSAFE_DETERMINISTIC_MODE.