Qu’est-ce qu’une attaque de réentrée et comment pouvez-vous la prévenir dans vos contrats ?

Comprendre les attaques de réentrée dans les contrats intelligents

1. Une attaque de réentrance se produit lorsqu'un contrat malveillant rappelle à plusieurs reprises une fonction vulnérable avant la fin de l'exécution initiale. Ce comportement récursif exploite l'ordre des appels externes et les changements d'état au sein d'un contrat intelligent.

2. La principale vulnérabilité réside dans les contrats qui envoient des fonds ou effectuent des appels externes avant de mettre à jour leur état interne. Un attaquant peut exploiter cette fenêtre pour retirer des fonds plusieurs fois en entrant à nouveau dans la fonction de retrait.

3. L'un des exemples les plus tristement célèbres est le piratage de DAO en 2016, où plus de 60 millions de dollars d'Ether ont été drainés en raison d'une faille de réentrée. L'attaquant a utilisé une fonction de secours pour invoquer de manière récursive le mécanisme de retrait.

4. Ces attaques ne se limitent pas aux transferts Ether. Tout appel externe à un contrat contrôlé par l’utilisateur peut potentiellement être transformé en arme si des garanties appropriées ne sont pas en place.

5. La réentrée reste l’un des risques de sécurité les plus critiques dans les applications décentralisées, en particulier dans les protocoles DeFi gérant de grandes quantités de fonds des utilisateurs.

Modèles courants qui permettent la réentrée

1. Les contrats qui suivent le modèle « appelez d'abord, mettez à jour plus tard » sont intrinsèquement sensibles. L'envoi d'Ether ou de jetons avant de réduire le solde d'un utilisateur permet aux attaquants de revenir avec un solde mis à jour reflétant toujours le montant d'origine.

2. Les fonctions qui reposent sur des appels de bas niveau comme call() , delegatecall() ou send() sans vérifications appropriées augmentent l'exposition. Ces méthodes déclenchent la fonction de secours ou de réception du destinataire, qui peut contenir une logique malveillante.

3. L’utilisation inadéquate des modèles de paiement pull-over-push contribue au risque. Les systèmes push qui envoient des fonds de manière proactive lors d’une transaction créent des ouvertures pour une exploitation récursive.

4. Les interactions contractuelles complexes sur plusieurs interfaces amplifient le danger. Lorsqu’un contrat en appelle un autre et que les deux ont des états mutables, le suivi du flux d’exécution devient difficile, ce qui augmente les risques de surveillance.

5. Même un code apparemment sécurisé peut être compromis si les mises à jour d'état ne sont pas atomiques et se produisent après des interactions externes.

Stratégies de prévention efficaces

1. Appliquez rigoureusement le modèle Contrôles-Effets-Interactions (CEI). Validez toujours les entrées, mettez à jour les variables d’état internes et effectuez ensuite seulement des appels externes. Cette séquence élimine la fenêtre de rentrée.

2. Utilisez des verrous mutex ou des gardes de réentrée fournis par des bibliothèques telles que ReentrancyGuard d'OpenZeppelin. Ceux-ci appliquent un mécanisme de verrouillage qui empêche la ré-entrée d’une fonction alors qu’elle est déjà en cours d’exécution.

3. Limitez l’utilisation des appels de bas niveau. Préférez les fonctions de transfert de haut niveau comme transfer() qui ont des protections intégrées, comme une limite de rémunération en gaz qui empêche souvent les exécutions récursives.

4. Mettez en œuvre des modèles de retrait au lieu de paiements directs. Permettez aux utilisateurs de lancer la récupération de fonds via une fonction distincte, minimisant ainsi le nombre d'appels externes lors d'opérations sensibles.

5. Des outils réguliers d'audit et d'analyse statique doivent être intégrés dans le cycle de vie du développement pour détecter les vecteurs de réentrée potentiels avant le déploiement.

Foire aux questions

Quel est le rôle des fonctions de repli dans les attaques par réentrance ? Les fonctions de secours s'exécutent automatiquement lorsqu'un contrat reçoit de l'Ether sans données. Les attaquants créent des solutions de secours malveillantes qui invoquent à nouveau les fonctions vulnérables, créant ainsi une boucle qui draine les fonds avant la finalisation de la transaction initiale.

La réentrée peut-elle se produire entre différentes fonctions dans un même contrat ? Oui. La réentrance interfonctionnelle se produit lorsqu'une fonction effectue un appel externe qui renvoie à une autre fonction du même contrat, exploitant un état partagé qui n'a pas été mis à jour. Une bonne gestion étatique et des gardes sont essentiels pour bloquer ces chemins.

Les contrats par procuration sont-ils à l’abri de la réentrée ? Non. Les contrats de proxy peuvent toujours être vulnérables si l'implémentation logique contient des appels externes non contrôlés. Étant donné que les proxys délèguent les appels à des contrats logiques évolutifs, toute faille dans la couche logique, y compris la réentrance, reste exploitable.

Quel est l’impact des limitations de gaz sur les tentatives de réentrée ? Certaines premières défenses reposaient sur la consommation de tout le gaz disponible pour bloquer la récursion. Cependant, les attaques modernes contournent ce problème en utilisant une estimation précise des gaz. Se fier uniquement aux limites de gaz n’est pas fiable ; les modèles de code structurel offrent une protection plus forte.