Comment sécuriser votre contrat intelligent contre les attaques de réentrance ?

Comprendre les vulnérabilités de réentrée

1. Les attaques de réentrance exploitent la capacité des contrats externes à rappeler le contrat vulnérable avant la fin de l'exécution initiale de la fonction.

2. Cela se produit lorsque les changements d'état ne sont pas finalisés avant les appels externes, permettant à un code malveillant de manipuler les soldes ou les indicateurs à plusieurs reprises.

3. Le tristement célèbre piratage de DAO en 2016 a démontré comment un modèle de retrait récursif a drainé plus de 60 millions de dollars d'ETH.

4. De telles vulnérabilités se développent dans les fonctions gérant les transferts, les retraits ou toute logique impliquant un appel externe suivi d'une mise à jour de l'état .

5. Les versions Solidity antérieures à la 0.8.0 ne disposaient pas de protections de réentrée intégrées, ce qui rendait la protection manuelle essentielle pour les déploiements existants.

Implémentation du modèle Contrôles-Effets-Interactions

1. Cette discipline architecturale exige que toutes les modifications d'état interne se produisent avant toute interaction externe.

2. Par exemple, la mise à jour du solde d'un utilisateur doit précéder un transfert d'appel ou un appel sur une autre adresse.

3. La violation de cet ordre ouvre la porte aux attaquants pour détourner le flux de contrôle et accéder à nouveau à la même fonction.

4. Même avec un classement approprié, les développeurs doivent vérifier qu'aucune fonction intermédiaire, comme des émetteurs ou des modificateurs d'événements, ne déclenche des appels externes involontaires.

5. Des outils tels que Slither et MythX peuvent détecter les écarts par rapport à ce modèle lors de l'analyse statique du bytecode et de la source.

Utilisation du modificateur ReentrancyGuard

1. ReentrancyGuard d'OpenZeppelin est un utilitaire largement audité qui verrouille une fonction à l'aide d'un indicateur booléen.

2. Le modificateur définit _status sur _ENTERED avant l'exécution et le réinitialise sur _NOT_ENTERED une fois terminé.

3. Tout appel imbriqué tentant de réintégrer la même fonction protégée sera annulé en raison du verrouillage actif.

4. Cela n’empêche pas la réentrance inter-fonctions à moins que tous les points d’entrée sensibles partagent la même instance de garde.

5. Les développeurs doivent s'assurer que la hiérarchie d'héritage initialise correctement l'état de garde et évite d'observer la variable interne.

Limitation des gaz comme stratégie d’atténuation

1. Limiter explicitement le gaz transféré dans les appels de bas niveau comme call.gas(2300) empêche les contrats du destinataire d'exécuter une logique complexe.

2. Cette technique imite la rémunération du gaz d'envoi et de transfert , qui limite l'exécution à 2 300 gaz.

3. Cependant, il est fragile de se fier uniquement aux limites de gaz : les futures mises à niveau de l'EVM ou les opcodes personnalisés peuvent modifier les coûts du gaz de manière imprévisible.

4. Cela rompt également la compatibilité avec les contrats exigeant plus qu'un minimum de gaz pour la logique de repli, tels que ceux effectuant l'exploitation forestière ou le rééquilibrage.

5. Les mesures d’atténuation basées sur le gaz devraient compléter, et non remplacer, les mesures de protection structurelles telles que les gardes de réentrée et les ordres de l’État.

Foire aux questions

Q : La réentrance peut-elle se produire dans des fonctions de vue ou pures ? R : Non. Ces fonctions ne peuvent pas exécuter d'opérations de changement d'état ou d'appels externes, éliminant ainsi la possibilité d'interférences récursives.

Q : L’utilisation de déléguécall empêche-t-elle la réentrée ? R : Pas intrinsèquement. Bien que déléguécall préserve le contexte de stockage de l'appelant, il ne bloque pas les modèles réentrants si la logique cible contient des interactions externes non protégées.

Q : La fonction de repli payable est-elle toujours dangereuse ? R : Seulement s’il effectue des mises à jour d’état ou des appels externes sans protection contre la réentrance. Une solution de repli minimale acceptant l’ETH sans effets secondaires présente un risque négligeable.

Q : Les modèles de proxy évolutifs augmentent-ils l'exposition à la réentrance ? R : Oui : si le contrat de mise en œuvre ne dispose pas de protections appropriées et que le proxy transfère les appels sans validation, les attaquants peuvent exploiter simultanément la logique du proxy et la logique métier.