Qu'est-ce que Reentrancy Attack ?
Une Reentrancy Attack se produit lorsqu'un contrat transfère le contrôle à un autre contrat durant un appel et que ce code externe retourne dans le premier contrat avant qu'il n'ait fini de mettre à jour ses enregistrements. Ce tour de synchronisation permet à l'attaquant de répéter des actions sensibles comme des retraits encore et encore. Imaginez demander un remboursement, puis revenir au comptoir avant que la caisse ne soit verrouillée.
« Seul du code ancien peut être touché par une Reentrancy Attack. » Faux. Tout contrat qui effectue un appel externe avant de verrouiller son propre état peut être vulnérable si la logique est négligente.
Comment fonctionne Reentrancy Attack
Bref. Un contrat intelligent typique possède une fonction de retrait qui envoie des fonds à l'appelant. Si elle envoie d'abord les fonds puis efface le solde après, un attaquant peut insérer un rappel et demander plus avant que le solde ne soit remis à zéro.
- Début : L'attaquant dépose des fonds pour paraître légitime.
- Appel : L'attaquant déclenche la fonction de retrait sur le contrat ciblé.
- Fallback : Le contrat cible envoie des fonds, ce qui exécute la fonction de fallback de l'attaquant.
- Répéter : Ce fallback appelle de nouveau la fonction de retrait avant que le solde soit mis à jour.
- Vidage : La boucle continue jusqu'à ce que le contrat n'ait plus de fonds ou de gas. Oui, c'est le tour.
Une seule erreur d'ordre, gros problème.
Pourquoi Reentrancy Attack est important
Cela importe car les bugs de synchronisation déplacent de l'argent réel, rapidement. De plus, c'est l'un de ces exploits classiques que tout développeur et tout utilisateur curieux devrait reconnaître d'un coup d'œil.
- Avantage : Connaître le schéma vous aide à repérer du code risqué et à protéger des fonds.
- Perspective : Il tire parti de la transparence publique puisque tout sur une blockchain est visible et peut être appelé.
- Pertinence : Vous le verrez dans la DeFi, sur des ponts, dans les trésoreries, et même dans les paiements de gouvernance pour les DAO.
Respectez l'ordre vérifications puis effets puis interactions. Mettez à jour les soldes d'abord, puis effectuez les appels externes. Ajoutez une simple protection contre la Reentrancy Attack pour plus de sécurité.
Caractéristiques clés de Reentrancy Attack
Voici ce qui le caractérise :
- Récursivité : Le code externe rappelle le même contrat avant qu'il ait fini.
- Ordre : Le bug apparaît quand l'envoi de fonds ou l'appel externe a lieu avant les mises à jour d'état.
- Croisé : Il peut rebondir entre plusieurs contrats, pas seulement une fonction.
- Actifs : Fonctionne avec ETH, tokens, et même des crédits comptables si le code est mal conçu.
Variations
Différentes variantes, même problème pour le code négligé :
- Simple : Réentrer dans la même fonction à plusieurs reprises.
- Croisé : Réentrer via une autre fonction dans le même contrat.
- Multi : Réentrer à travers deux contrats ou plus en boucle.
- Lecture seule : Influencer des vues ou des oracles de prix pour tromper des écritures ultérieures.
Corriger une Reentrancy Attack ne se limite pas à une seule fonction. Passez en revue chaque appel externe, ajoutez des tests pour les chaînes d'appels étranges, et planifiez des audits réguliers.
Exemple
L'exploit de 2016 contre The DAO utilisait une boucle de réentrance sur la fonction de retrait avant que les soldes ne soient effacés, vidant une trésorerie massive en quelques minutes.
Fait amusant
La maxime communautaire vérifications puis effets puis interactions vient des premiers guides de sécurité et est restée car elle est courte, mémorable et efficace.
Conclusion
Version courte à garder en tête : si du code externe peut vous appeler avant que vous n'ayez terminé votre propre tenue de comptes, supposez qu'il le fera et vous pourriez lui offrir de l'argent gratuitement. C'est une Reentrancy Attack.