Analyse de l'attaque par réinjection de prêts flash sur le projet Jarvis Network
Le 15 janvier 2023, le projet Jarvis_Network a été attaqué, entraînant une perte de 663 101 MATIC. En analysant la pile d'appels des transactions d'attaque, il a été constaté qu'il existait une logique de réentrance. Au cours du processus de réentrance, l'appel de la même fonction du même contrat avec les mêmes paramètres a donné des valeurs de retour très différentes.
La réinjection se produit dans la fonction remove_liquidity. Cette fonction renvoie les jetons ajoutés par l'utilisateur lors de la suppression de la liquidité. Étant donné que Polygon est isomorphe à l'EVM, le transfert de MATIC au contrat déclenche une réinjection.
Une analyse approfondie révèle que le problème réside dans l'implémentation de la fonction getUnderlyingPrice. Cette fonction implique plusieurs appels de contrats, affectant finalement la valeur de retour de la fonction get_virtual_price. La valeur de retour de la fonction get_virtual_price est influencée par la variable self.D, dont la mise à jour se fait après le transfert.
Lors de la suppression de la liquidité, MATIC est transféré au contrat d'attaque, puis la fonction fallback est rappelée pour interroger le prix. Étant donné que self.D est mis à jour après le transfert, cela entraîne une erreur dans l'obtention du prix précédent. Le processus de la méthode de suppression de liquidité est le suivant : 1) destruction du LP de l'utilisateur ; 2) envoi des fonds stakés de l'utilisateur ; 3) mise à jour de self.D.
self.D est utilisé pour le calcul des prix et sera également mis à jour lors de l'ajout de liquidité. Les fonds de liquidité de l'attaquant sont relativement importants, normalement la valeur de self.D sera beaucoup plus faible. Mais l'attaquant effectue une réentrée à l'étape 2 et emprunte à un prix 10 fois supérieur au prix d'origine. Cela est dû au fait que la valeur de self.D augmente lors de l'ajout de liquidité, mais n'est pas mise à jour à temps lors de la suppression de liquidité.
Bien que la méthode remove_liquidity utilise @nonreentrant('lock') pour prévenir les réentrées, un attaquant peut réentrer dans d'autres contrats pour emprunter des fonds, rendant ainsi le verrou de réentrée inefficace.
La principale raison de cette attaque est que la logique de modification des variables après un appel externe a entraîné une anomalie dans l'obtention des prix. La réentrance inter-contrat a rendu le verrou de réentrance inefficace. Il est recommandé aux développeurs du projet de procéder à un audit de sécurité rigoureux, de placer la modification des variables avant l'appel externe et d'adopter une méthode d'obtention des prix à partir de plusieurs sources de données. Suivre la norme de codage "d'abord vérifier, ensuite écrire dans la variable, puis effectuer l'appel externe" (Checks-Effects-Interactions) peut améliorer la sécurité et la stabilité du projet.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
9 J'aime
Récompense
9
6
Partager
Commentaire
0/400
All-InQueen
· 08-05 00:42
Blockchain encore une fois frappé par une tempête, c'est l'enfer.
Voir l'originalRépondre0
HalfBuddhaMoney
· 08-02 05:37
On ne peut pas en obtenir autant...
Voir l'originalRépondre0
ZeroRushCaptain
· 08-02 05:37
Encore un qui est tombé, toute l'épargne est partie en fumée. Perdre de l'argent, Sam Altman, en avant !
Voir l'originalRépondre0
ForkLibertarian
· 08-02 05:29
Avec une telle lenteur, il est déjà trop tard pour faire une Cut Loss ou un Rug Pull.
Voir l'originalRépondre0
StakeTillRetire
· 08-02 05:24
Un autre incident de réentrance, je suis déprimé.
Voir l'originalRépondre0
SighingCashier
· 08-02 05:13
Vous avez raté, n'est-ce pas ? Encore une vulnérabilité de réentrance.
Jarvis Network a subi une attaque de réinjection de Prêts Flash, entraînant une perte de 663,101 MATIC
Analyse de l'attaque par réinjection de prêts flash sur le projet Jarvis Network
Le 15 janvier 2023, le projet Jarvis_Network a été attaqué, entraînant une perte de 663 101 MATIC. En analysant la pile d'appels des transactions d'attaque, il a été constaté qu'il existait une logique de réentrance. Au cours du processus de réentrance, l'appel de la même fonction du même contrat avec les mêmes paramètres a donné des valeurs de retour très différentes.
La réinjection se produit dans la fonction remove_liquidity. Cette fonction renvoie les jetons ajoutés par l'utilisateur lors de la suppression de la liquidité. Étant donné que Polygon est isomorphe à l'EVM, le transfert de MATIC au contrat déclenche une réinjection.
Une analyse approfondie révèle que le problème réside dans l'implémentation de la fonction getUnderlyingPrice. Cette fonction implique plusieurs appels de contrats, affectant finalement la valeur de retour de la fonction get_virtual_price. La valeur de retour de la fonction get_virtual_price est influencée par la variable self.D, dont la mise à jour se fait après le transfert.
Lors de la suppression de la liquidité, MATIC est transféré au contrat d'attaque, puis la fonction fallback est rappelée pour interroger le prix. Étant donné que self.D est mis à jour après le transfert, cela entraîne une erreur dans l'obtention du prix précédent. Le processus de la méthode de suppression de liquidité est le suivant : 1) destruction du LP de l'utilisateur ; 2) envoi des fonds stakés de l'utilisateur ; 3) mise à jour de self.D.
self.D est utilisé pour le calcul des prix et sera également mis à jour lors de l'ajout de liquidité. Les fonds de liquidité de l'attaquant sont relativement importants, normalement la valeur de self.D sera beaucoup plus faible. Mais l'attaquant effectue une réentrée à l'étape 2 et emprunte à un prix 10 fois supérieur au prix d'origine. Cela est dû au fait que la valeur de self.D augmente lors de l'ajout de liquidité, mais n'est pas mise à jour à temps lors de la suppression de liquidité.
Bien que la méthode remove_liquidity utilise @nonreentrant('lock') pour prévenir les réentrées, un attaquant peut réentrer dans d'autres contrats pour emprunter des fonds, rendant ainsi le verrou de réentrée inefficace.
La principale raison de cette attaque est que la logique de modification des variables après un appel externe a entraîné une anomalie dans l'obtention des prix. La réentrance inter-contrat a rendu le verrou de réentrance inefficace. Il est recommandé aux développeurs du projet de procéder à un audit de sécurité rigoureux, de placer la modification des variables avant l'appel externe et d'adopter une méthode d'obtention des prix à partir de plusieurs sources de données. Suivre la norme de codage "d'abord vérifier, ensuite écrire dans la variable, puis effectuer l'appel externe" (Checks-Effects-Interactions) peut améliorer la sécurité et la stabilité du projet.