gosentry

trail-of-bits форкнула тулчейн Go, чтобы go test -fuzz=FuzzX выполнялся через Rust-runner на базе libafl, а не через встроенный фаззер Go. Автор пишет harness с использованием обычного API testing.F; gosentry перехватывает колбэк f.Fuzz, собирает Go-архив с точками входа в стиле libFuzzer и запускает его прямо в процессе.

Мотивация в одном предложении: фаззер из стандартной библиотеки Go не умеет разрешать ограничения путей, не принимает структурированные входные данные, не поддерживает грамматики и молча игнорирует специфичные для Go классы багов (переполнения целых чисел, утечки горутин, состояния гонки, бесконечные циклы). gosentry закрывает эти четыре пробела, не заставляя автора тестов изучать новый фреймворк. Подробный разбор - в gosentry-go-fuzzing-fork.

Отличия от стандартного go test -fuzz

• Движок: LibAFL (Rust) вместо встроенного в Go мутатора на основе покрытия кода
• Типы входных данных: структуры, срезы, массивы, указатели (см. structure-aware-fuzzing) - не только примитивные типы
• Режим грамматик: генерация на базе Nautilus по правилам вывода из JSON-массивов (см. grammar-based-fuzzing)
• Обнаружение багов: встраиваемые компилятором проверки переполнения целых чисел, проверки усечения go-panikint, детектор гонок Go, поиск утечек горутин через goleak, отслеживание таймаутов, а также флаг --panic-on для кодовых баз, которые логируют ошибки вместо паники
• CLI: расширяет go test -fuzz флагами вроде --catch-races=true --catch-leaks=true --focus-on-new-code=false --generate-coverage

Использование

./bin/go test -fuzz=FuzzHarness \
    --focus-on-new-code=false \
    --catch-races=true \
    --catch-leaks=true

go test -fuzz=FuzzTarget --generate-coverage

Сам harness:

func FuzzExample(f *testing.F) {
    f.Add(exampleValue)
    f.Fuzz(func(t *testing.T, input []byte) {
        TargetFunction(input)
    })
}

байт-в-байт совпадает с тем, что пишется для стандартного фаззинга в Go. Вся механическая разница сводится к вызываемому тулчейну.

Первые находки

Дифференциальный фаззинг различных реализаций одной спецификации протокола, в основном в экосистеме Ethereum L2:

• Optimism/Kona: неизвестный тип пакета -> DoS-паника
• Optimism: расхождение в Brotli-каналах между Kona и op-node
• Optimism: несоответствие парсинга фреймов спецификации
• Revm: баг с увеличением nonce при неудавшемся депозите, приводивший к расхождению state root

Ограничения

• Форк тулчейна - необходимо постоянно отслеживать апстрим-релизы Go
• Для сборки runner'а LibAFL в окружении требуется тулчейн Rust
• Заметные накладные расходы по времени выполнения при включении всех детекторов (гонки + утечки + переполнение + покрытие) - нужно настраивать под конкретную кампанию
• Фаззинг-бинарник отличается от продакшен-сборки; инструмент не заменяет укрепление продакшена

Watchlist

Проект внесён в watchlist - это суточный форк с переписанной логикой от одной компании по безопасности. Отслеживаем частоту синхронизации с апстримом Go, число сторонних контрибьюторов вне Trail of Bits, переживёт ли интеграция LibAFL регулярные квартальные изменения в тулчейне Go, и подтвердится ли результативность по числу найденных багов в других экосистемах Go помимо крипты и L2.