Vulnérabilité Reentrancy : Comment Identifier, Exploiter et Prévenir

Dans le monde des contrats intelligents, la reentrancy est considérée comme l’une des vulnérabilités les plus dangereuses. Cet article vous aidera non seulement à comprendre ce qu’est une attaque de reentrancy, mais aussi comment la prévenir efficacement. Des techniques de base aux solutions avancées, nous explorerons les moyens de protéger l’ensemble de votre projet.

Comment Fonctionne la Reentrancy : Mécanisme d’Attaque de Base

Pour comprendre la reentrancy, il faut d’abord saisir le concept fondamental : un contrat intelligent peut appeler un autre contrat, et ce dernier peut rappeler le premier pendant son exécution.

Imaginez deux contrats : ContractA détient 10 Ether et ContractB y a envoyé 1 Ether. Lorsqu’il appelle la fonction de retrait, il vérifie si le solde est suffisant. Si oui, Ether est renvoyé à ContractB. À ce moment-là, si aucune protection n’est en place, c’est là que l’attaquant peut exploiter la faille.

Dans une attaque de reentrancy classique, l’attaquant utilise deux fonctions : attack() pour lancer l’attaque, et fallback() pour rappeler la fonction. La fonction fallback est une fonction spéciale en Solidity — elle n’a pas de nom, pas de paramètres, et est appelée automatiquement chaque fois que de l’Ether est envoyé au contrat sans données.

Étapes de l’Attaque de Reentrancy

Suivez le processus étape par étape. L’attaquant appelle attack() depuis son contrat. À l’intérieur, il appelle withdraw() de ContractA.

ContractA, en recevant cet appel, vérifie si le solde de ContractB est supérieur à zéro. Comme il y a 1 Ether, la vérification passe. Ensuite, ContractA envoie 1 Ether à ContractB, ce qui active sa fonction fallback. À ce moment, ContractA a encore 9 Ether, mais surtout — le solde de ContractB dans la blockchain n’a pas encore été mis à jour à 0.

C’est là que la faille apparaît : la fallback appelle à nouveau withdraw() de ContractA. ContractA vérifie à nouveau le solde de ContractB — il est toujours de 1 Ether ! Pourquoi ? Parce que la ligne de code qui met le solde à 0 n’a jamais été exécutée, elle se trouve après l’envoi d’Ether.

Ce processus se répète : appel withdraw → vérification du solde (toujours > 0) → envoi d’Ether → fallback → rappel de withdraw… jusqu’à ce que tout l’Ether de ContractA soit drainé.

Analyse du Code : Quand la Reentrancy Devient Réalité

Le contrat EtherStore est un exemple classique de contrat vulnérable. Il possède une fonction deposit() pour déposer des fonds, et withdrawAll() pour retirer tout. Le problème réside dans la façon dont withdrawAll() est implémentée : elle vérifie la condition, envoie l’Ether, puis met à jour le solde.

Le contrat Attack exploite cette faille. Dans son constructeur, l’attaquant fournit l’adresse de EtherStore, ce qui lui permet d’appeler ses fonctions. La fallback du contrat Attack est appelée chaque fois qu’EtherStore envoie de l’Ether, et elle continue d’appeler withdrawAll() tant qu’il reste de l’Ether. La fonction attack() démarre le processus en envoyant 1 Ether dans EtherStore pour passer la vérification initiale.

Résultat : toute la réserve d’EtherStore est drainée en une seule transaction.

Trois Stratégies pour Protéger un Contrat Contre la Reentrancy

Pour sécuriser les contrats intelligents, il existe trois niveaux de protection, du plus simple au plus complet.

Modèle noReentrant : Solution de Protection de Base

La méthode la plus simple consiste à utiliser le modificateur noReentrant(). Un modificateur est une fonction spéciale en Solidity qui modifie le comportement d’autres fonctions sans en réécrire le code.

L’idée est simple : lorsqu’une fonction est protégée par noReentrant(), elle verrouille le contrat pendant son exécution. Toute tentative de réappeler cette fonction échouera parce que la variable de verrouillage empêche l’entrée. Une fois la fonction terminée, le verrou est levé, permettant d’autres appels.

Cette solution est efficace pour protéger une seule fonction, mais ne suffit pas pour des scénarios plus complexes.

Modèle Check-Effect-Interaction : Prévenir la Reentrancy Multi-Fonction

La deuxième technique, plus robuste, est l’application du pattern Check-Effect-Interaction. Au lieu de protéger une seule fonction, cette méthode modifie la logique de votre code.

Le principe clé : vérifier les conditions d’abord (Check), mettre à jour l’état immédiatement après (Effect), puis interagir avec d’autres contrats (Interaction). Cela empêche l’attaquant d’exploiter la faille, car lors de ses rappels, le solde est déjà à jour.

Au lieu de mettre à jour balance[msg.sender] = 0 après l’envoi d’Ether, vous le faites avant. Ainsi, même si fallback est rappelée plusieurs fois, la vérification échouera car le solde est à 0.

Cette méthode protège contre la reentrancy de façon globale, même si plusieurs fonctions de retrait existent.

GlobalReentrancyGuard : Protection Globale sur Tout le Projet

Pour des projets complexes avec plusieurs contrats interconnectés, une solution plus avancée est le GlobalReentrancyGuard.

Au lieu de verrouiller à chaque fonction, cette méthode verrouille à l’échelle du projet entier. Vous créez un contrat séparé qui stocke une variable d’état de verrouillage global, et tous les autres contrats y font référence.

Imaginez : un attaquant appelle une fonction dans le contrat ScheduledTransfer. Après vérification, il envoie de l’Ether à AttackTransfer. La fallback d’AttackTransfer est déclenchée et tente de rappeler ScheduledTransfer. Mais, grâce au verrou global, la tentative est bloquée immédiatement.

Cette approche est particulièrement utile pour les grands projets avec plusieurs contrats, où la reentrancy peut se produire entre différents contrats.

Choisir la Bonne Technique pour Votre Projet

Le choix de la stratégie dépend de la complexité de votre projet. Si votre contrat a peu de fonctions interactives, noReentrant() suffit. Si vous avez plusieurs fonctions de retrait, le pattern Check-Effect-Interaction est recommandé. Pour les projets de grande envergure avec plusieurs contrats, le GlobalReentrancyGuard offre une protection complète.

Quelle que soit la méthode choisie, l’essentiel est de comprendre comment la reentrancy fonctionne, pour pouvoir la détecter et la prévenir de manière proactive.

Pour recevoir chaque jour des mises à jour sur la sécurité des contrats intelligents, examiner le code source et suivre les tendances en Web3, consultez des ressources spécialisées en sécurité Solidity.