EF/CF - le Fuzzer de Contrats (Ethereum smart) Extrêmement Rapide

EF/CF est une nouvelle approche du fuzzing de contrats intelligents : au lieu d'utiliser un nouveau fuzzer développé sur mesure, il réutilise l'infrastructure de fuzzing existante pour le code C/C++ et l'applique aux contrats intelligents. Actuellement, AFL++ est le fuzzer principalement pris en charge, bien qu'il existe également un support très rudimentaire pour libfuzzer et honggfuzz.

Pourquoi utiliser l'infrastructure de fuzzing existante ?

Vitesse. Nous pouvons fuzzer plus rapidement. Nous atteignons régulièrement environ 20 000 exécutions/s/cœur.
Les fuzzers de code natif sont bien conçus et optimisés.
Guidage par couverture adéquat, gestion de file d'attente, relecture déterministe de cas de test, etc.

Quels sont les problèmes que nous rencontrons en cours de route ?

Nous devons enseigner au fuzzer la structure : à savoir ce qu'est une transaction et ce qu'est l'ABI du contrat intelligent. Nous utilisons un mutateur personnalisé pour cela : ./src/ethmutator/
Pour augmenter la vitesse et obtenir un retour de couverture utile, nous traduisons le bytecode EVM en C++ à l'aide d'un transpileur personnalisé ./src/evm2cpp/

Ce dépôt est le point d'entrée principal du projet EF/CF. Il contient tout le code pertinent sous forme de sous-projets dans ./src/ et plusieurs scripts pratiques pour l'installation, des scripts pour lancer des campagnes de fuzzing et divers ensembles de données pour tester le fuzzer (et le comparer à d'autres outils).

Vous devez adapter le script pour configurer les outils et le nombre d'exécutions. ### Mise en place d'une expérience de fuzzing Ici, nous utilisons l'expérience `tests` comme exemple. Remplacez simplement la chaîne `tests` par le nom de l'expérience dans les étapes suivantes : 1. Rassemblez votre jeu de données dans `./data/`, par exemple le jeu de données `./data/tests` avec des contrats de test. Pour les contrats Solidity, nous disposons d'un `Makefile` générique pour compiler les contrats : `sol.Makefile`. Vous pouvez le réutiliser si vous le souhaitez, voir `./data/tests/Makefile` pour un exemple. 2. Créez un script pour générer les artefacts de compilation, y compris toute étape de pré-traitement/collecte nécessaire. Par exemple, pour le jeu de données `tests`, nous avons le script `./scripts/build-tests.sh`. Les artefacts de compilation doivent être stockés dans `./builds/tests/${contract}.build.tar.xz`. 3. Créez un script pour lancer la campagne de fuzzing, par exemple pour le jeu de données `tests`, créez un script appelé `./scripts/fuzz-tests.sh`. En général, vous pouvez utiliser la fonction commune de campagne de fuzzing de `./scripts/common.sh`. Regardez `fuzz-tests.sh` comme modèle. 4. Les résultats de `fuzz-tests.sh` seront stockés dans `./results/run-fuzz-tests/`. 5. Pour résumer les résultats, nous fournissons `./scripts/summarize.py` pour les scripts de lancement basés sur bash et `./scripts/summarize_l.py` pour les scripts de lancement Python (l'outil `efcfuzz`). Vous devrez peut-être adapter ces scripts en fonction de votre étape 3. ### Expériences de fuzzing existantes #### Benchmarks * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/multi">`./data/multi`</a> contient le benchmark de scalabilité que nous avons utilisé pour évaluer comment un outil d'analyse passe à l'échelle sur des séquences de transactions plus longues. Il se compose de trois types de contrats : * `multi_gen_*.sol` - des contrats synthétisés automatiquement, qui effectuent une série de `require(input <= MAGIC)` puis définissent une variable d'état interne. Si toutes les variables d'état sont définies, alors le `selfdestruct` (ou oracle echidna) peut être déclenché. * `multi_man_complex_*.sol` - des variantes créées manuellement qui fonctionnent de manière similaire aux contrats de type `multi_gen`, mais présentent des contraintes un peu plus délicates (par exemple, d'autres choses que l'égalité et l'inégalité avec une valeur magique) * `justlen_*.sol` - ceux-ci sont tirés de l'[exemple echidna-parade](https://github.com/crytic/echidna-parade/blob/main/examples/justlen.sol) * `multi_simple_*.sol` - des vérifications de cohérence qui vérifient qu'un fuzzer/outil peut en théorie trouver des bogues nécessitant 9 ou 10 transactions. Ici, l'analyseur doit simplement appeler 10 fonctions dans le bon ordre sans aucun argument. C'est assez facile pour la plupart des outils d'analyse. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/throughput">`./data/throughput`</a> contient les contrats que nous avons utilisés pour évaluer le débit. Il s'agit d'une sélection de contrats de tailles variées. Notez que nous avons corrigé toutes les vulnérabilités de ces contrats, afin que les vulnérabilités trouvées n'affectent pas les mesures de débit. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/cov-max-testset">`./data/cov-max-testset`</a> contient les contrats que nous avons utilisés pour la comparaison des fuzzers basés sur la couverture de code. #### Détection de bogues * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/ethbmc-vuln">`./data/ethbmc-vuln`</a> liste des contrats qu'EthBMC a détectés comme vulnérables. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/ethbmc-timeouts">`./data/ethbmc-timeouts`</a> liste des contrats pour lesquels EthBMC a arrêté l'analyse en raison d'un dépassement de délai. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/reentrancy">`./data/reentrancy`</a> un ensemble de contrats vulnérables aux attaques de réentrance. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/sailfish-dao-tp">`./data/sailfish-dao-tp`</a> un ensemble de contrats qui ont été vérifiés comme contenant un bogue de réentrance dans le cadre de l'[étude 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> liste de tous les contrats, pour lesquels [sailfish](https://github.com/ucsb-seclab/sailfish/tree/master/data/bugs) a trouvé un bogue de réentrance. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/sereum">`./data/sereum`</a> une liste de contrats vulnérables aux attaques de réentrance selon [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> contrats issus des smartbugs curatés, classés comme bogues de « contrôle d'accès » ([smartbugs github](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> contrats issus des smartbugs curatés, classés comme bogues de « réentrance » ([smartbugs github](https://github.com/smartbugs/smartbugs/tree/master/dataset/reentrancy)) #### Tests Les jeux de données suivants contiennent des contrats de test synthétiques de base pour tester les capacités du fuzzer : * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/tests">`./data/tests`</a> tests de base rassemblés à partir de plusieurs sources qui vérifient les capacités de base d'un fuzzer. Tous utilisent un oracle selfdestruct. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/tests-not-vuln">`./data/tests-not-vuln`</a> identique aux tests, mais ne devrait pas être détecté comme vulnérable. * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/properties-tests">`./data/properties-tests`</a> tests pour le fuzzing basé sur les propriétés * <a href="https://github.com/uni-due-syssec/efcf-framework/blob/main/data/assertions-tests">`./data/assertions-tests`</a> tests pour le fuzzing des assertions. ## Fuzzing plus en détail Nous utilisons des scripts wrapper pour lancer le fuzzer réel (AFL++ dans notre cas). Cela se fait automatiquement lors de l'utilisation du lanceur `efcfuzz`.```bash $ cd data/tests $ make SimpleDAO.evm2cpp $ cd ../../src/eEVM/ $ env AFL_BENCH_UNTIL_CRASH=1 ./fuzz/launch-aflfuzz.sh SimpleDAO

## Lecture du format des cas de test Le format des cas de test est conçu pour le fuzzing et n'est pas aussi simple à lire. Vous devez être conscient de plusieurs subtilités. * Le format des cas de test est considéré comme une « file » de transactions pouvant être exécutées. Dès qu'un problème est rencontré, le traitement du cas de test s'arrête. Cela inclut : * Lorsqu'une transaction est annulée (revert). * Toute erreur rencontrée par le code de harnais (harness code). * Tout bug déclenché et détecté. Par conséquent, un cas de test imprimé ne correspond pas nécessairement à ce qui est exécuté : il peut y avoir des transactions à la fin qui ne sont pas exécutées. Vérifiez la sortie verbeuse et utilisez le minimizer pour vous en débarrasser ! * De même, il peut y avoir trop de `returns` ou des drapeaux `reenter` erronés. Utilisez le minimizer de cas de test pour éliminer cela. * Un contrat n'est ré-entré que lorsqu'il y a une autre transaction dans la liste après la transaction censée effectuer la réentrance (c'est-à-dire qu'il y a une autre entrée suivante dans la file). * Même si le drapeau `reenter` est défini sur une certaine valeur, cela ne signifie pas nécessairement que le contrat est ré-entré, seulement que le code du harnais essaiera de le faire si possible. Par exemple, si le contrat n'effectue pas d'appel, le drapeau `reenter` est ignoré car aucune réentrance n'est possible. En général, le minimizer supprimera les drapeaux `reenter` erronés. En général, la plupart de ces problèmes disparaissent lorsque vous utilisez le minimizer de cas de test, il est donc toujours bon d'utiliser celui-ci avant d'analyser les cas de test générés. ## Fausses alertes connues Nous avons observé plusieurs types de fausses alertes qui semblent récurrentes lors du fuzzing de contrats avec EF/CF. * Les contrats qui versent de l'Ether par conception. L'oracle de bugs de gain d'Ether d'EF/CF identifiera ces contrats comme vulnérables, alors qu'ils fonctionnent comme prévu : * Contrats de jeu : de nombreux contrats de jeu comportent une forme d'aléatoire, ce qui est déjà une mauvaise pratique sur Ethereum. Cependant, certains contrats de jeu sont implémentés d'une manière qui vous oblige à deviner, par exemple, les deux derniers chiffres du hash du bloc suivant ou quelque chose de similaire. Cela peut être activé via un schéma d'engagement (commitment scheme), c'est-à-dire que la première transaction engage l'utilisateur sur une certaine valeur et la seconde déclenche la devinette et le paiement en cas de victoire. Ces contrats ne sont généralement pas exploitables sur une véritable blockchain. Cependant, dans la blockchain simulée d'EF/CF, le fuzzer peut adapter l'engagement après avoir observé la valeur de la seconde transaction. Ce fait est important pour qu'EF/CF atteigne une meilleure couverture de code. Cependant, cela facilite également l'identification par EF/CF d'une séquence de transactions (TX) qui permet au fuzzer de gagner de manière déterministe dans le contrat de jeu. * Contrats qui versent des intérêts : il existe de nombreux petits contrats qui vous permettent d'investir de l'Ether puis de verser un certain pourcentage d'intérêts tous les `N` blocs. L'attaquant simulé d'EF/CF est capable d'attendre `N` blocs puis de recevoir le paiement des intérêts, ce qui est à nouveau détecté par l'oracle de bugs de gain d'Ether. * Airdrops : certains contrats de jetons permettent des airdrops, c'est-à-dire qu'ils distribuent des jetons à toute personne qui en fait la demande jusqu'à ce que certaines limites soient atteintes. Par exemple, les airdrops ne sont souvent activés que pendant une courte période. Si un tel contrat est déployé dans EF/CF, il y a de fortes chances que la limite de temps soit définie de manière à ce que les airdrops soient toujours actifs. EF/CF détecte alors un gain d'Ether si les jetons distribués peuvent être revendus. * Signalement hâtif des `DELEGATECALL` contrôlables : actuellement, nous signalons un delegatecall contrôlable dès qu'il est invoqué. Cependant, il existe de nombreux contrats qui comportent des fonctions permettant intentionnellement à l'appelant d'effectuer un delegatecall vers une adresse arbitraire. Ces fonctions annulent cependant inconditionnellement la transaction immédiatement après le delegatecall. Cela empêche toute mise à jour d'état ou tout transfert d'Ether de persister. Généralement, ces fonctions contiennent des mots comme « simulate » dans leur nom de fonction, ce qui les rend faciles à repérer. * Cela pourrait être corrigé dans EF/CF en reportant le signalement jusqu'à la fin de l'exécution. Cependant, cela complique pas mal l'oracle de bugs. * Actuellement, il n'y a aucun plan pour corriger cela. * Initialiseur appelable : nous avons observé qu'en fuzziant des contrats exportés depuis la blockchain, EF/CF est parfois capable d'appeler des fonctions d'initialisation, même si le contrat a déjà été initialisé. Normalement, cela devrait déclencher un revert, mais ce n'est pas le cas dans l'environnement EVM d'EF/CF. Appeler à nouveau l'initialiseur conduit souvent à des gains d'Ether triviaux, car par exemple l'initialiseur définit une variable *owner* ou quelque chose de similaire. * Nous ne sommes pas encore certains de la cause racine de ce problème. Cependant, il est généralement facile à repérer, car la fonction d'initialisation est typiquement appelée `initializer`, `init` ou similaire. ## Pièges courants Nous avons fait de notre mieux pour rendre cet outil quelque peu utilisable, mais il s'agit encore d'un prototype de recherche. Attendez-vous à ce que des choses cassent. Voici quelques problèmes courants que nous avons observés : * *Q : J'obtiens une erreur de compilation étrange due à une macro `TOKENPASTE`.* R : Cela arrive souvent lorsque `efcfuzz` devine le mauvais nom de contrat (c'est-à-dire qu'il devine un contrat abstrait) ; essayez de passer `--name YourContract` pour spécifier le contrat cible.

efcf-framework

Populaires

L'article EF/CF

Citation dans les travaux académiques

Installation / Configuration

Sous-modules Git

Sur 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

Clé API Etherscan

Démarrage d'EF/CF avec le lanceur

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