Qu’est-ce qu’une attaque de réentrée et comment les contrats intelligents peuvent-ils s’en défendre ?

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

1. Une attaque de réentrée 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. Cet exploit profite de l'ordre dans lequel les changements d'état et les appels externes sont exécutés.

2. L'exemple le plus tristement célèbre est le piratage DAO de 2016, où un attaquant a drainé plus de 60 millions de dollars en retirant de manière récursive des fonds d'un contrat qui n'avait pas mis à jour les soldes avant d'envoyer de l'Ether.

3. Ces attaques ciblent généralement les fonctions qui effectuent des appels externes vers des contrats non fiables tout en conservant des variables d'état critiques dans un état incohérent.

4. Pendant l'appel récursif, la fonction de repli ou de réception de l'attaquant déclenche à nouveau la même logique de retrait, contournant ainsi les contrôles d'accès ou les vérifications de solde.

5. La principale vulnérabilité réside dans la violation du modèle de vérification des effets et des interactions, dans lequel les modifications d'état doivent toujours précéder les appels externes pour empêcher toute manipulation pendant l'exécution.

Modèles vulnérables courants dans Solidity

1. Les fonctions qui envoient de l'Ether ou des jetons à des adresses contrôlées par l'utilisateur sans mettre à jour au préalable la comptabilité interne sont des cibles privilégiées pour la réentrée.

2. Les contrats utilisant des appels de bas niveau, comme les appels avec des transferts Ether natifs, sont particulièrement menacés car ils transfèrent tout le gaz restant, permettant une logique de rappel complexe.

3. La logique qui repose sur les validations post-appel échoue lorsque l'appel lui-même déclenche une entrée récursive, rendant ces vérifications inefficaces jusqu'à ce que les dommages soient causés.

4. Les structures successorales peuvent involontairement exposer des fonctions si les contrats parentaux ne prévoient pas de protections appropriées, même si les contrats enfants semblent sécurisés.

5. Les bibliothèques ou les modèles de proxy peuvent propager des vulnérabilités si le mécanisme d'appel délégué permet une corruption de l'état via des configurations de stockage partagées.

Mécanismes de défense efficaces

1. Implémentez rigoureusement le modèle Contrôles-Effets-Interactions : validez toujours les entrées, mettez à jour les variables d'état, puis procédez aux appels externes.

2. Utilisez des gardes de réentrance provenant de bibliothèques établies comme ReentrancyGuard d'OpenZeppelin, qui utilisent des verrous mutex pour bloquer les entrées récursives.

3. Préférez le transfert de fonds par virement ou envoi plutôt que par appel , car ces méthodes limitent le transfert de gaz et réduisent la surface d'attaque.

4. Adopter des modèles de paiement pull-over-push dans lesquels les utilisateurs réclament des fonds plutôt que de les voir automatiquement envoyés, éliminant ainsi les risques d'appels sortants.

5. Appliquez des outils d'analyse statique rigoureux et une vérification formelle pendant le développement pour détecter les chemins de récursion potentiels avant le déploiement.

Foire aux questions

Qu’est-ce qui rend une fonction de repli dangereuse dans les scénarios de réentrée ? Une fonction de secours devient dangereuse lorsqu'elle contient une logique qui réinvoque les fonctions métier du contrat appelant. Si le contrat d'origine n'a pas mis à jour son état avant de passer un appel externe, ce déclencheur récursif peut exploiter des soldes ou des autorisations obsolètes.

La réentrée peut-elle se produire à travers plusieurs interactions contractuelles ? Oui, la réentrée entre fonctions est possible lorsque différentes fonctions au sein du même contrat accèdent à un état partagé sans synchronisation appropriée. Un attaquant pourrait déclencher une fonction qui appelle en externe, puis utiliser la solution de secours pour entrer une deuxième fonction vulnérable avant que les mises à jour d'état ne se produisent.

Les contrats non-Ether sont-ils à l’abri de la réentrée ? Non, les contrats de jetons gérant les transferts ERC-20 peuvent également être exploités. Si un transfert de jeton déclenche un hook de récepteur (comme approbation + rappel) et que le contrat de réception manipule l'état de l'expéditeur en cours de transfert, des exploits récursifs similaires apparaissent.

Comment les mises à niveau du compilateur aident-elles à atténuer la réentrée ? Les versions plus récentes de Solidity incluent des valeurs par défaut plus sûres et des avertissements pour les anti-modèles connus. Par exemple, des spécifications de visibilité explicites et des règles améliorées en matière d’allocation d’essence réduisent les comportements involontaires. Cependant, les fonctionnalités du compilateur ne peuvent à elles seules éliminer les défauts logiques nécessitant une discipline architecturale.