EF/CF - сверхбыстрый фаззер смарт-контрактов Ethereum

EF/CF — это новый подход к фаззингу смарт-контрактов: вместо создания нового фаззера с нуля, он переиспользует существующую инфраструктуру фаззинга кода на C/C++ для смарт-контрактов. В настоящее время основным поддерживаемым фаззером является AFL++, хотя также есть некоторая базовая поддержка libfuzzer и honggfuzz.

Зачем использовать существующую инфраструктуру фаззинга?

Скорость. Мы можем фаззить быстрее. Обычно мы получаем около 20k execs/sec/core.
Фаззеры для нативного кода хорошо спроектированы и оптимизированы.
Правильная coverage-guidance, управление очередью, детерминированное воспроизведение тест-кейсов и т.д.

С какими проблемами мы сталкиваемся на этом пути?

Нам нужно объяснить фаззеру структуру: а именно, что такое транзакция и что такое ABI смарт-контракта. Для этого мы используем собственный мутатор: ./src/ethmutator/
Чтобы повысить скорость и получать полезную обратную связь о покрытии, мы транслируем EVM-байткод в C++ с помощью собственного транспилятора ./src/evm2cpp/

Этот репозиторий — основная точка входа для проекта EF/CF. Он содержит весь соответствующий код в виде подпроектов в ./src/, а также несколько вспомогательных скриптов для установки, скриптов для запуска фаззинг-кампаний и различные наборы данных для тестирования фаззера (и сравнения с другими инструментами).

— содержит весь исходный код, необходимый для сборки и запуска EF/CF; для воспроизводимости все прямые зависимости добавлены как git-подмодули.

Вы также можете указать дополнительные пользовательские темы/хеши событий для отслеживания в файле с помощью `--event-assertions-list ./path/to/eventslist.txt`. Как и в случае со списком свойств выше, формат можно получить, используя `solc --hashes`, и скопировав хеши и имена событий в файл списка событий. По умолчанию EF/CF игнорирует события, которые не были выпущены целевым контрактом. Если вы хотите изменить это, используйте `--event-assertions-target-only=n`. (Примечание: вы можете использовать `--assertions`, чтобы включить проверку как событий, так и твердотельных утверждений) **Пример: Фаззинг для проверки утверждений Solidity ^0.8** В настоящее время мы не поддерживаем фаззинг произвольных утверждений в коде Solidity для версий Solidity ниже 0.8. Ранее утверждения Solidity просто вызывали опкод `invalid`, что приводило к довольно жёсткому откату (revert). Версия Solidity 0.8 изменила поведение: вместо использования опкода `invalid` для отката транзакций теперь используется механизм `revert`, и ошибки передаются обратно вызывающему коду. Мы можем использовать такой тип распространения ошибок как оракул ошибок в EF/CF. В настоящее время EF/CF поддерживает проверку типа ошибки Solidity `Panic(uint256)`. [Дополнительная информация об ошибках Solidity.](https://docs.soliditylang.org/en/v0.8.0/control-structures.html?highlight=assert#panic-via-assert-and-error-via-require)``` efcfuzz --sol-assertions \ --timeout 120 --until-crash \ --source ./data/assertions-tests/overflow.sol

Вам нужно адаптировать скрипт для настройки инструментов и количества запусков. ### Настройка фаззинг-эксперимента Здесь мы используем эксперимент `tests` в качестве примера. Просто замените строку `tests` на имя эксперимента в следующих шагах: 1. Соберите свой набор данных в `./data/`, например, набор данных `./data/tests` с тестовыми контрактами. Для контрактов Solidity у нас есть универсальный `Makefile` для сборки контрактов: `sol.Makefile`. Вы можете использовать его повторно, если хотите, см. `./data/tests/Makefile` в качестве примера. 2. Создайте скрипт для создания артефактов сборки, включая все необходимые шаги предварительной обработки/сбора данных. Например, для набора данных `tests` мы имеем скрипт `./scripts/build-tests.sh`. Артефакты сборки должны храниться в `./builds/tests/${contract}.build.tar.xz`. 3. Создайте скрипт для запуска фаззинг-кампании, например, для набора данных `tests` создайте скрипт с именем `./scripts/fuzz-tests.sh`. Обычно можно использовать общую функцию фаззинг-кампании из `./scripts/common.sh`. Посмотрите на `fuzz-tests.sh` как на шаблон. 4. Результаты `fuzz-tests.sh` будут сохранены в `./results/run-fuzz-tests/`. 5. Для обобщения результатов мы предоставляем `./scripts/summarize.py` для скриптов-лаунчеров на bash и `./scripts/summarize_l.py` для скриптов-лаунчеров на python (инструмент `efcfuzz`). Возможно, вам потребуется адаптировать эти скрипты в зависимости от вашего шага 3. ### Существующие фаззинг-эксперименты #### Бенчмарки * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/multi">`./data/multi`</a> содержит бенчмарк масштабируемости, который мы использовали для оценки того, насколько хорошо инструмент анализа масштабируется на более длинные последовательности транзакций. Он состоит из трёх типов контрактов: * `multi_gen_*.sol` - автоматически синтезированные контракты, которые выполняют набор проверок `require(input <= MAGIC)` и затем устанавливают внутреннюю переменную состояния. Если все переменные состояния установлены, то `selfdestruct` (или оракул echidna) может быть инициирован. * `multi_man_complex_*.sol` - созданные вручную варианты, которые работают аналогично контрактам типа `multi_gen`, но содержат немного более хитрые ограничения (например, не только равенство и неравенство с магическим значением) * `justlen_*.sol` - они взяты из [примера echidna-parade](https://github.com/crytic/echidna-parade/blob/main/examples/justlen.sol) * `multi_simple_*.sol` - проверки работоспособности, которые подтверждают, что фаззер/инструмент может в теории найти ошибки, требующие 9 или 10 транзакций. Здесь анализатору нужно лишь вызвать 10 функций в правильном порядке без аргументов. Это довольно просто для большинства инструментов анализа. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/throughput">`./data/throughput`</a> содержит контракты, которые мы использовали для оценки пропускной способности. Это выборка контрактов с разным размером. Обратите внимание, что мы исправили все уязвимости в этих контрактах, чтобы найденные уязвимости не влияли на измерения пропускной способности. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/cov-max-testset">`./data/cov-max-testset`</a> содержит контракты, которые мы использовали для сравнения фаззеров на основе покрытия кода. #### Обнаружение ошибок * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/ethbmc-vuln">`./data/ethbmc-vuln`</a> список контрактов, которые EthBMC определил как уязвимые. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/ethbmc-timeouts">`./data/ethbmc-timeouts`</a> список контрактов, где EthBMC остановил анализ из-за тайм-аута. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/reentrancy">`./data/reentrancy`</a> набор контрактов, уязвимых к атакам повторного входа. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/sailfish-dao-tp">`./data/sailfish-dao-tp`</a> набор контрактов, которые, как было подтверждено, содержат ошибку повторного входа в рамках [исследования sailfish](https://github.com/ucsb-seclab/sailfish/tree/master/data/ground-truth). * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/sailfish-dao">`./data/sailfish-dao`</a> список всех контрактов, где [sailfish](https://github.com/ucsb-seclab/sailfish/tree/master/data/bugs) обнаружил ошибку повторного входа. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/sereum">`./data/sereum`</a> список контрактов, уязвимых к атакам повторного входа, согласно [Sereum](https://github.com/uni-due-syssec/sereum-results). * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/smartbugs-curated-accesscontrol">`./data/smartbugs-curated-accesscontrol`</a> контракты из курируемого набора smartbugs, классифицированные как ошибки «управления доступом» ([репозиторий smartbugs](https://github.com/smartbugs/smartbugs/tree/master/dataset/access_control)) * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/smartbugs-curated-reentrancy">`./data/smartbugs-curated-reentrancy`</a> контракты из курируемого набора smartbugs, классифицированные как ошибки «повторного входа» ([репозиторий smartbugs](https://github.com/smartbugs/smartbugs/tree/master/dataset/reentrancy)) #### Тесты Следующие наборы данных содержат базовые синтетические тестовые контракты для проверки возможностей фаззера: * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/tests">`./data/tests`</a> базовые тесты, собранные из различных источников, которые проверяют базовые возможности фаззера. Все используют selfdestruct оракул. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/tests-not-vuln">`./data/tests-not-vuln`</a> то же, что и тесты, но не должны определяться как уязвимые. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/properties-tests">`./data/properties-tests`</a> тесты для фаззинга на основе свойств * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/assertions-tests">`./data/assertions-tests`</a> тесты для фаззинга на утверждения. ## Фаззинг подробнее Мы используем скрипты-обёртки для запуска непосредственно фаззера (в нашем случае AFL++). Это делается автоматически при использовании лаунчера `efcfuzz`.```bash $ cd data/tests $ make SimpleDAO.evm2cpp $ cd ../../src/eEVM/ $ env AFL_BENCH_UNTIL_CRASH=1 ./fuzz/launch-aflfuzz.sh SimpleDAO

Затем он скомпилируется и будет фаззить в течение довольно длительного времени. После этого вы можете выполнить `cd ./fuzz/out/SimpleDAO*`, чтобы просмотреть результаты фаззинга. Наши скрипты-обёртки выполняют дополнительную работу помимо запуска программы `afl-fuzz`, то есть в основном постобработку результатов. Кроме того, будут созданы несколько удобных скриптов для анализа полученных тестовых случаев. * `./a.sh` — выводит человекочитаемое представление тестового случая, обёртка вокруг `efuzzcaseanalyzer`. * `./r.sh` — запускает тестовый случай с теми же настройками, что и при запуске фаззера. * `./m.sh` — минимизирует тестовый случай с теми же настройками, что и при запуске фаззера. * `./c.sh` — анализирует «цепочку» тестовых случаев, которые привели к данному тестовому случаю. Полезен для анализа/оптимизации фаззера. Вы можете быстро увидеть, какой тестовый случай был получен какой цепочкой мутаций над какими записями очереди. Требует `fzf`. Существуют также некоторые другие удобные отчёты, например: * `./bugs` и `./bugtypes`, которые обобщают все обнаруженные баги. * `./crashes_min`, который содержит минимизированные краши всех экземпляров `afl-fuzz`. **Просмотр покрытия кода базовых блоков EVM**```bash $ cat coverage-percent-all.evmcov 70.73170731707317

## Чтение формата тест-кейса Формат тест-кейса ориентирован на фаззинг и не так прост для чтения. Следует учитывать несколько тонкостей. * Формат тест-кейса рассматривается как «очередь» транзакций, которые могут быть выполнены. Как только возникает любая проблема, обработка тест-кейса останавливается. Это включает: * Когда транзакция откатывается (revert). * Любую ошибку, обнаруженную обвязочным кодом. * Любой баг, который срабатывает и обнаруживается. Как следствие, распечатанный тест-кейс не обязательно соответствует тому, что выполняется — в конце могут быть транзакции, которые не выполняются. Проверьте подробный вывод и используйте минимизатор, чтобы избавиться от них! * Аналогично, может быть слишком много `returns` или ложных флагов `reenter`. Используйте минимизатор тест-кейсов, чтобы избавиться от них. * Повторный вход в контракт происходит только тогда, когда в списке есть другая транзакция после той, которая должна выполнить повторный вход (т.е. в очереди есть следующая запись). * Даже если флаг `reenter` установлен в какое-либо значение, это не обязательно означает, что в контракт будет выполнен повторный вход; это лишь означает, что обвязочный код попытается сделать это, если возможно. Например, если контракт не выполняет вызов, флаг `reenter` игнорируется, поскольку возможности для повторного входа нет. Обычно минимизатор удаляет все ложные флаги `reenter`. В целом многие из этих проблем исчезают при использовании минимизатора тест-кейсов, так что всегда полезно применять его перед анализом сгенерированных тест-кейсов. ## Известные ложные срабатывания Мы наблюдали несколько типов ложных срабатываний, которые, судя по всему, регулярно возникают при фаззинге контрактов с помощью EF/CF. * Контракты, которые по замыслу выплачивают Ether. Оракул ошибок прироста Ether (Ether-gains) в EF/CF помечает такие контракты как уязвимые, хотя они работают как задумано: * Азартные контракты: многие азартные контракты используют ту или иную форму случайности, что само по себе уже является плохой практикой в Ethereum. Однако некоторые азартные контракты реализованы так, что вынуждают угадывать, например, последние две цифры следующего blockhash или что-то подобное. Это может быть реализовано через схему обязательств (commitment scheme): первая транзакция фиксирует обязательство пользователя перед определённым значением, а вторая запускает угадывание и выплату в случае выигрыша. Такие контракты обычно не эксплуатируемы в реальном блокчейне. Однако в симулированном блокчейне EF/CF фаззер может скорректировать обязательство после того, как значение во второй транзакции уже наблюдается. Этот факт важен для EF/CF для достижения лучшего покрытия кода. Однако он также позволяет EF/CF легко находить последовательность транзакций, которая позволяет фаззеру детерминированно выигрывать в азартном контракте. * Контракты, выплачивающие проценты: существует множество небольших контрактов, которые позволяют инвестировать Ether, а затем выплачивают определённый процент в качестве процентов каждые `N` блоков. Симулированный атакующий EF/CF способен подождать `N` блоков и затем получить процентную выплату, что снова обнаруживается оракулом ошибок Ether-gains. * Airdrop'ы: некоторые токен-контракты поддерживают airdrop'ы, то есть просто раздают токены всем, кто их запросит, пока не будет достигнут определённый лимит. Например, airdrop'ы часто доступны только в течение короткого периода времени. Если такой контракт развёрнут в EF/CF, высока вероятность, что временной лимит установлен так, что airdrop'ы всё ещё активны. Тогда EF/CF фиксирует прирост Ether (Ether-gains), если полученные через airdrop токены можно снова продать. * Немедленное сообщение об управляемом `DELEGATECALL`: сейчас мы сообщаем об управляемом delegatecall сразу после его вызова. Однако существует множество контрактов с функциями, которые намеренно позволяют вызывающему выполнить delegatecall на произвольный адрес. Но эти функции безусловно откатывают (revert) транзакцию сразу после delegatecall. Это предотвращает сохранение любых изменений состояния или переводов ether. Обычно такие функции содержат в названии слова вроде «simulate», поэтому их легко обнаружить. * Это можно было бы исправить в EF/CF, отложив сообщение до конца выполнения. Однако это значительно усложняет оракул ошибок. * Сейчас планов по исправлению нет. * Вызываемый инициализатор: Мы заметили, что при фаззинге контрактов, экспортированных из блокчейна, EF/CF иногда может вызывать функции-инициализаторы, даже если контракт уже был инициализирован. Обычно это должно вызывать revert, но в среде EVM от EF/CF этого не происходит. Повторный вызов инициализатора часто приводит к тривиальному приросту Ether, поскольку, например, инициализатор устанавливает переменную *owner* или что-то подобное. * Мы пока не уверены в первопричине этой проблемы. Однако её обычно легко обнаружить, поскольку функция-инициализатор обычно называется `initializer`, `init` или подобным образом. ## Частые ловушки Мы постарались сделать всё возможное, чтобы этот инструмент был хоть как-то пригоден к использованию, но это всё ещё исследовательский прототип. Будьте готовы к тому, что что-то может ломаться. Вот некоторые распространённые проблемы, которые мы наблюдали: * *В: У меня возникает странная ошибка компиляции из-за макроса `TOKENPASTE`.* О: Это часто происходит, когда `efcfuzz` угадывает неправильное имя контракта (т.е. угадывает абстрактный контракт). Попробуйте передать `--name YourContract`, чтобы указать целевой контракт.

efcf-framework

Популярное

Статья об EF/CF

Цитирование в академических работах

Installation / Setup

Git-подмодули

На Mac OS / M1

make sure that the submodules are initialized

pull the linux/amd64 base image

build the ef/cf image

launch the EF/CF container

Ключ API Etherscan

Запуск EF/CF с помощью лаунчера

efcfuzz can handle the combined.json output of the solidity compiler

but you can also explicitely pass the runtime and deploy bytecode and the ABI

definition. This is useful if you want to fuzz contracts using other

compilers (e.g., vyper).

configure system

run fuzzer (somewhat sandboxed and using a tmpfs for less SSD wear)

roughly equivalent to running