Comprendre les attaques de réentrée dans les contrats intelligents (explication du hack DAO)

Qu’est-ce qu’une attaque de réentrée ?

1. Une attaque de réentrée se produit lorsqu'un contrat externe rappelle le contrat actuel avant la fin de l'exécution initiale.

2. Cette vulnérabilité est due à une mauvaise gestion de l'état, en particulier lorsque les variables d'état sont mises à jour après des appels externes plutôt qu'avant.

3. L'attaquant déploie un contrat malveillant contenant une fonction de secours qui appelle de manière récursive la fonction vulnérable dans le contrat cible.

4. Chaque appel récursif réintègre le même chemin logique, drainant les fonds à plusieurs reprises sans que le solde ne soit mis à jour jusqu'à ce que la pile d'appels entière se déroule.

5. De telles attaques exploitent le modèle d'exécution synchrone et monothread d'Ethereum dans lequel les appels externes conservent le flux de contrôle dans le contexte d'appel.

L'incident DAO : une panne historique

1. Le DAO était une organisation autonome décentralisée lancée en 2016 sur Ethereum, conçue comme un fonds de capital-risque régi par des règles de contrats intelligents.

2. Son code permettait aux détenteurs de jetons de se séparer du DAO et de récupérer de l'éther en appelant une fonction splitDAO .

3. Cette fonction a transféré l'éther à l'adresse du demandeur avant de mettre à jour le solde interne, créant ainsi une fenêtre de réentrée classique.

4. Un attaquant a déployé un contrat avec une fonction de repli qui a déclenché à nouveau splitDAO lors de la réception de fonds.

5. Au cours de plusieurs appels imbriqués, plus de 3,6 millions d'ETH, d'une valeur de plus de 50 millions de dollars à l'époque, ont été siphonnés avant que la transaction ne soit annulée ou interrompue.

Comment le modèle d'exécution d'Ethereum permet la réentrance

1. Chaque appel externe dans Solidity s'exécute dans le même contexte transactionnel, préservant la mémoire, le stockage et la visibilité de la pile d'appels.

2. Il n'y a pas de protection contre la réentrée automatique à moins qu'elle ne soit explicitement implémentée via des modèles tels que Contrôles-Effets-Interactions.

3. Les limites de gaz n’empêchent pas la récursion ; ils ne limitent que le calcul total et les fonctions de repli nécessitent un minimum de gaz pour s'exécuter.

4. L'EVM n'impose pas d'isolement entre l'appelant et l'appelé : les changements d'état effectués par l'appelé sont visibles par l'appelant pendant son exécution en cours.

5. Les développeurs sous-estiment souvent à quel point les interactions contractuelles peuvent devenir profondément interdépendantes, en particulier lorsque des jetons ou des oracles tiers sont impliqués.

Modèles de code courants qui invitent à la réentrée

1. Mettre à jour les soldes ou les indicateurs après avoir envoyé de l'éther ou appelé des contrats externes au lieu d'avant.

2. Utiliser call.value()() sans valider les valeurs de retour ni limiter la profondeur de récursion.

3. S'appuyer sur this.balance pour la comptabilité au lieu de suivre les soldes dans les variables de stockage.

4. Implémentation de modèles de retrait sans verrous, mutex ou modificateurs de réentrance tels que ReentrancyGuard d'OpenZeppelin.

5. Échec de l'audit de la logique héritée, en particulier lors de l'utilisation de modèles de proxy ou de contrats évolutifs où l'appel délégué préserve le contexte.

Foire aux questions

Q : La réentrée peut-elle se produire dans les transferts ERC-20 ? R : Les fonctions de transfert ERC-20 standard ne déclenchent pas d'appels externes, la réentrée native n'est donc pas possible. Cependant, des extensions comme transferFrom combinées avec des hooks (par exemple, dans ERC-777) introduisent des surfaces de rappel où la réentrance peut se produire.

Q : Le piratage de DAO a-t-il été réversible à cause d'un hard fork ? R : Oui. La communauté Ethereum a exécuté un hard fork pour restaurer les fonds volés en réécrivant l’historique de la chaîne, entraînant la séparation d’Ethereum et d’Ethereum Classic.

Q : Les versions modernes de Solidity empêchent-elles la réentrée par défaut ? R : Non. Solidity v0.8.x inclut un comportement arithmétique et de retour plus sûr, mais n'injecte pas automatiquement de protection par réentrance. Les développeurs doivent toujours appliquer manuellement des modèles défensifs.

Q : L'utilisation de require(msg.sender.call{value: montant}('')) est-elle plus sûre que address.send() ? R : Ni l’un ni l’autre n’est intrinsèquement sûr. Les deux autorisent la réentrée s’ils sont utilisés avant les mises à jour d’état. Le facteur critique est l’ordre des interactions, et non le mécanisme d’appel spécifique.