Auteur : Artela Chinese blog, medium# Résumé

Les attaques par réentrance restent un défi. Les méthodes de défense existantes se concentrent principalement sur le niveau du code source du protocole, qui ne prend effet qu'avant que le contrat n'entre dans l'état d'exécution.

La "protection d'exécution" est un complément important à la sécurité DeFi. Elle vise à "protéger les résultats d'exécution" et à garantir que l'exécution du protocole est conforme à sa conception attendue.

La conception de l'EVM ne prend pas en charge la "protection d'exécution", car le contrat intelligent ne peut pas accéder aux informations de contexte complètes de l'état d'exécution

Artela explore un paradigme de couche d'exécution EVM + Extension, améliore la couche d'exécution pour éliminer les attaques de rentrée

Artela implémente des extensions de "protection d'exécution" en chaîne via la programmation Aspect

Nous montrons étape par étape comment empêcher les attaques de réentrance sur le contrat Curve via Aspect

Pourquoi les attaques par réentrance sont toujours un défi malgré les contrôles de risques existants

Bien que les attaques par réentrance soient un problème bien connu et que de nombreux contrôles des risques aient été mis en place, des incidents de sécurité impliquant de telles attaques ont continué à se produire au cours des deux dernières années :

Curve Finance Attack (juillet 2023) - 60 millions de dollars Curve a subi une attaque de réentrance en raison d'un défaut de compilation dans son langage de programmation contractuelle Vyper.

Attaque du protocole d'origine (novembre 2022) - Le projet Stablecoin de 7 millions de dollars Origin Dollar (OUSD) a subi une attaque de réentrance.

Attaque du protocole Siren (septembre 2021) - 3,5 millions de dollars, le pool AMM subit une attaque de réentrance.

Attaque de Cream Finance (août 2021) - 18,8 millions de dollars, les attaquants ont exploité une vulnérabilité de réentrance pour un emprunt secondaire.

À l'heure actuelle, la prévention des attaques par réentrance se concentre sur le niveau du code source des contrats intelligents, notamment l'intégration de ReentrancyGuard d'OpenZeppelin et la réalisation d'audits de sécurité sur les codes logiques des contrats afin d'éviter les risques de sécurité prédéfinis.

Cette approche, connue sous le nom de solution "boîte blanche", vise à éviter les vulnérabilités au niveau du code source afin de minimiser les erreurs logiques. Cependant, son principal défi est l'incapacité de se défendre contre des dangers cachés inconnus.

"Traduire" un contrat du code source à l'exécution réelle est un processus difficile. Chaque étape peut entraîner des problèmes imprévus pour les développeurs, et le code source du contrat lui-même peut ne pas couvrir entièrement toutes les situations potentielles. Dans le cas de Curve, même si le code source du protocole est correct, il peut toujours y avoir des écarts entre l'exécution finale et la conception prévue du protocole en raison de problèmes de compilateur.

Il ne suffit pas de s'appuyer sur la sécurité du protocole au niveau du code source et de la compilation. Même si le code source semble sans faille, des vulnérabilités peuvent toujours apparaître de manière inattendue en raison de problèmes de compilateur.

Nous avons besoin d'une protection d'exécution

Contrairement aux mesures de contrôle des risques existantes qui sont concentrées au niveau du code source du protocole et prennent effet avant l'exécution, la protection d'exécution implique que les développeurs de protocoles écrivent des règles de protection d'exécution et des opérations pour gérer les circonstances imprévues d'exécution. Cela facilite l'évaluation en temps réel et la réponse aux résultats d'exécution de l'exécution.

La protection d'exécution est essentielle pour améliorer la sécurité DeFi et constitue un ajout important aux mesures de sécurité existantes. En protégeant le protocole d'une manière "boîte noire", il améliore la sécurité en garantissant que le résultat opérationnel final est cohérent avec la conception prévue du protocole, sans interférer directement avec l'exécution du code contractuel.

Défis liés à la mise en œuvre de la protection d'exécution

Malheureusement, la conception EVM ne prend pas en charge la protection d'exécution en chaîne car les contrats intelligents n'ont pas accès au contexte d'exécution complet.

Comment surmonter ce défi ? Nous pensons que les prérequis suivants sont nécessaires :

Un module dédié qui donne accès à toutes les informations sur les contrats intelligents, y compris l'ensemble du contexte de la transaction.

L'autorisation nécessaire est obtenue à partir du contrat intelligent, donnant au module le droit d'annuler les transactions si nécessaire.

Assurez-vous que la fonctionnalité du module prend effet après l'exécution du contrat intelligent et avant la soumission de l'état.

L'EVM est actuellement confrontée à des limites pour relever les défis ci-dessus et ne peut pas s'adapter à d'autres innovations. Sous le paradigme de la blockchain modulaire, la couche d'exécution doit explorer la percée d'aller au-delà de l'EVM.

L'idée d'Artela est l'extension native EVM +, en construisant la couche d'extension native WASM d'EVM pour réaliser aller au-delà d'EVM.

Présentation de la programmation d'aspect

Nous avons lancé Aspect Programming, un cadre de programmation pour la blockchain Artela qui prend en charge la mise à l'échelle native sur la blockchain.

Aspect est un module d'extension natif programmable, qui est utilisé pour intégrer dynamiquement des fonctions personnalisées dans la blockchain au moment de l'exécution, en tant que complément modulaire aux contrats intelligents, et améliorer les fonctionnalités de la chaîne.

La caractéristique d'Aspect est qu'il peut accéder à l'API au niveau du système de la couche de base de la blockchain et ajouter une logique d'extension à chaque point de jonction du cycle de vie de la transaction. Les contrats intelligents peuvent lier des aspects spécifiques pour déclencher des fonctions étendues. Lorsqu'une transaction invoque un contrat intelligent, la transaction est également traitée par l'aspect associé au contrat.

Comment Aspect Programming implémente la protection d'exécution

Aspect peut enregistrer l'état d'exécution de chaque appel de fonction et empêcher la réentrance lors de l'exécution de la fonction de rappel. Lorsqu'un appel réentrant se produit pendant l'exécution de la fonction de rappel, Aspect détecte et annule immédiatement la transaction, empêchant les attaquants d'exploiter les vulnérabilités de réentrance. Avec cette approche, Aspect élimine efficacement les attaques de réentrance, garantissant la sécurité et la stabilité des contrats intelligents.

Aspect implémente des propriétés clés pour la protection à l'exécution :

Peut être déclenché après l'exécution du contrat intelligent et avant la soumission de l'état : les modules Aspect peuvent être configurés pour s'activer après l'exécution du contrat intelligent mais avant la soumission de l'état.

Accès complet au contexte de transaction : Aspect peut accéder au contexte complet de la transaction, y compris l'ensemble des informations de transaction (méthodes, paramètres, etc.), la pile d'appels (tous les appels de contrat internes pendant l'exécution), les changements de contexte d'état et tous les événements déclenchés par la transaction.

Capacité d'appel système : Aspect peut effectuer des appels système et initier des retracements de transaction si nécessaire.

Liaison et autorisation avec des contrats intelligents : les contrats intelligents peuvent être liés à Aspect et accorder à Aspect l'autorisation de participer au traitement des transactions.

Implémenter Aspect pour la protection de réentrance

Dans ce chapitre, nous expliquons comment implémenter la protection d'exécution d'Aspect sur la chaîne.

Un véritable aspect "Contract Protection Intent" peut être déployé au point de jonction de "preContractCall" et "postContractCall" pour empêcher les attaques de rentrée.

preContractCall : déclenché avant l'exécution de l'appel de contrat croisé

postContractCall : déclenché après l'exécution de l'appel de contrat croisé

Pour la protection contre la réentrance, notre objectif est d'empêcher la réentrance du contrat tant que l'appel n'est pas terminé. Avec Aspect, nous pouvons y parvenir en ajoutant une logique spécifique à des points de coupure dans le cycle de vie des transactions.

Dans le point cut "preContractCall", Aspect surveille la pile des appels de contrat. S'il y a des appels en double dans la pile d'appels (c'est-à-dire une réentrance inattendue dans notre appel verrouillé), l'aspect annulera l'appel.

Déployez le contrat Curve et empêchez les attaques de rentrée

Nous avons écrit un contrat fictif Curve et forgé une attaque de réentrance pour reproduire ce processus de manière plus compréhensible. Le code du contrat est le suivant :

On peut voir que les deux add_liquidity et remove_liquidity du contrat ci-dessus sont protégés par le même verrou de verrouillage de rentrée, ce qui signifie que si la protection de rentrée fonctionne normalement, la fonction protégée ne peut pas être réintégrée en changeant le verrou (par exemple, dans remove _liquidity appelle add_liquidity).

Compilez le contrat ci-dessus avec le compilateur vyper 0.2.15, 0.2.16 ou 0.3.0 (ces versions ont des problèmes de protection de réentrance connus).

Nous déployons ensuite le contrat victime ci-dessus et l'attaquons avec le contrat suivant :

Pour simuler une attaque réelle, la méthode d'attaque de ce contrat tente de ressaisir add_liquidity à partir de la méthode remove_liquidity via sa fonction de secours. Si la réentrance se produit réellement, on peut observer dans le reçu qu'un événement AddLiquidity est consigné avant l'événement RemoveLiquidity.

Utilisons maintenant Aspect pour protéger le contrat attaqué. Avant de faire ce qui suit, veuillez suivre les étapes suivantes :

1. Déployer Aspect

2. Liez le contrat de la victime avec Aspect

Si vous n'êtes pas familier avec les opérations Aspect, vous pouvez d'abord consulter notre guide du développeur.

Après avoir fait ce qui précède, essayons maintenant d'appeler à nouveau la méthode d'attaque pour vérifier si l'opération réussira.

À partir de l'image animée (vous pouvez voir le lien d'origine à la fin de l'article), nous pouvons voir que la transaction réentrante a été annulée, ce qui signifie que notre Aspect protège avec succès le contrat victime des attaques de réentrée.

en conclusion

La récente attaque contre Curve démontre une fois de plus qu'aucun protocole n'est totalement sécurisé à 100 %. Il ne suffit pas de se concentrer sur la sécurité aux niveaux de la source et de la compilation du protocole. Même si le code source semble être sans faille, des vulnérabilités peuvent toujours apparaître de manière inattendue en raison de problèmes de compilateur.

Pour améliorer la sécurité de DeFi, la protection de l'exécution devient critique. En protégeant le protocole d'une manière "boîte noire", en veillant à ce que l'exécution du protocole soit cohérente avec sa conception prévue, il peut empêcher efficacement les attaques de rentrée au moment de l'exécution.

Nous avons forké le contrat Curve et simulé entièrement sa récente attaque de réentrance, et reproduit l'ensemble du processus d'une manière plus compréhensible. En utilisant la programmation d'aspects comme nouvelle approche de la protection d'exécution en chaîne, nous montrons étape par étape comment protéger les contrats des victimes avec des aspects. Notre objectif est d'aider à éliminer les attaques de réentrée dont les protocoles DeFi comme Curve peuvent souffrir, améliorant ainsi la sécurité dans l'ensemble de l'espace DeFi.

Avec Aspect Programming, les développeurs peuvent non seulement obtenir une protection d'exécution en chaîne dans l'espace de sécurité, mais également permettre des cas d'utilisation innovants sans précédent tels que les intentions, le JIT et l'automatisation en chaîne. De plus, ce framework général basé sur le SDK Cosmos supportera non seulement la blockchain Artela, mais supportera également d'autres blockchains pour construire des extensions natives basées sur leurs propres couches d'exécution.