Qu’est-ce qu’une attaque de réentrance dans les contrats intelligents ?

Comprendre les attaques de réentrée

1. Une attaque de réentrance se produit lorsqu'un contrat malveillant rappelle à plusieurs reprises une fonction vulnérable d'un autre contrat avant la fin de l'exécution initiale.

2. Cet exploit exploite le mécanisme d'appel externe dans les contrats intelligents Ethereum, où le contrôle est transféré à une adresse externe avant que les changements d'état ne soient finalisés.

3. L'attaquant déploie un contrat contenant une fonction de repli ou de réception qui déclenche des invocations récursives de la logique de retrait ou de transfert de la cible.

4. Étant donné qu'Ethereum exécute les appels de manière synchrone et monothread et n'applique pas les mises à jour de l'état atomique par défaut, les soldes ou les indicateurs peuvent rester inchangés pendant la fenêtre de rappel.

5. En conséquence, les fonds peuvent être prélevés plusieurs fois sur le même solde sans contrôles appropriés, violant ainsi l’invariant économique prévu du système.

Exemple historique célèbre : le hack DAO

1. En juin 2016, l'organisation autonome décentralisée connue sous le nom de DAO a été compromise pour environ 3,6 millions d'ETH , évalués à l'époque à plus de 50 millions de dollars.

2. La vulnérabilité résidait dans une fonction de partage qui permettait aux utilisateurs de retirer leur part après l'adoption d'une proposition, mais mettait à jour le solde du contributeur après le transfert de fonds.

3. Un attaquant a déployé un contrat avec une fonction de repli qui a appelé de manière récursive la fonction split avant la mise à jour du solde.

4. Chaque appel récursif lit la valeur du solde d'origine, permettant des retraits répétés du même montant alloué.

5. L’incident a déclenché un hard fork de la blockchain Ethereum, ce qui a fait d’Ethereum et d’Ethereum Classic deux chaînes distinctes.

Conditions techniques permettant la réentrée

1. Un appel externe vers une adresse non fiable doit précéder les modifications d’état critiques telles que les mises à jour du solde ou le basculement des indicateurs d’accès.

2. Le contrat doit s'appuyer sur des variables de stockage mutables qui reflètent la propriété ou les droits sans appliquer de gardes de réentrée.

3. L'absence de modèles mutex, comme l'utilisation d'un booléen verrouillé ou de modificateurs de réentrance, laisse les points d'entrée non protégés dans les contextes d'appel imbriqués.

4. L'utilisation d'appels de bas niveau comme call() au lieu d'alternatives plus sûres comme transfer() ou send() augmente le risque en raison du manque de restrictions sur les allocations de gaz et du comportement de retour automatique.

5. Les contrats héritant de bibliothèques obsolètes ou non auditées peuvent exposer involontairement des fonctions avec des surfaces de réentrance héritées.

Stratégies d'atténuation déployées aujourd'hui

1. Le modèle Contrôles-Effets-Interactions exige la validation des conditions, la mise à jour de l'état interne et ensuite seulement l'exécution d'appels externes.

2. Les gardes de réentrée, tels que ReentrancyGuard d'OpenZeppelin, utilisent un booléen verrouillé pour empêcher la rentrée de fonction pendant l'exécution active.

3. L'utilisation de transfer() ou send() au lieu de raw call() impose une limite de 2 300 gaz, rendant les fonctions de secours incapables d'exécuter une logique complexe, y compris d'autres appels réentrants.

4. Les outils d'analyse statique comme Slither et MythX détectent les vecteurs de réentrance potentiels pendant le développement et les pipelines CI.

5. Les cadres de vérification formelle tels que Certora et KEVM valident les invariants de contrat sous des séquences d'appels arbitraires, y compris des invocations externes imbriquées.

Foire aux questions

T1. Des attaques par réentrée peuvent-elles se produire sur des blockchains autres qu’Ethereum ? A1. Oui. Toute chaîne compatible EVM, y compris BNB Chain, Polygon et Arbitrum, est également susceptible si les contrats reproduisent le même modèle d'interaction défectueux. Les chaînes non-EVM avec une sémantique d'appel externe similaire, comme les invocations inter-programmes de Solana dans certaines conditions, sont également confrontées à des risques analogues.

Q2. L'utilisation des instructions require() est-elle suffisante pour empêcher la réentrée ? A2. Non. Les instructions Require vérifient les conditions préalables mais ne bloquent pas la rentrée. Ils fonctionnent avant les changements d'état et ne peuvent pas restreindre les rappels ultérieurs une fois les appels externes effectués.

Q3. Les contrats évolutifs basés sur un proxy introduisent-ils des surfaces de réentrée supplémentaires ? A3. Oui. Si le contrat de mise en œuvre ne dispose pas d'une protection contre la réentrance et que le proxy transfère les appels sans intercepter ou valider la profondeur des appels, les modèles évolutifs peuvent hériter ou amplifier les vulnérabilités existantes.

Q4. Les prêts flash peuvent-ils déclencher une réentrée même sans contrats malveillants ? A4. Oui. Les attaques basées sur les prêts flash combinent souvent la manipulation de l'oracle des prix avec la réentrée pour drainer les pools de liquidités ou les protocoles de prêt, comme le montrent les exploits contre dYdX, Harvest Finance et BurgerSwap, qui reposent tous sur des appels externes non surveillés au sein de chemins critiques.