GMX a subi une attaque de hacker, avec des pertes dépassant 40 millions de dollars. Les attaquants ont exploité une vulnérabilité de réentrance et ont ouvert une position courte dans le cadre de l'activation de la fonctionnalité de levier, pour mener l'attaque.
La racine du problème réside dans l'utilisation incorrecte de la fonction executeDecreaseOrder. Le premier paramètre de cette fonction aurait dû être un compte externe (EOA), mais l'attaquant a passé une adresse de contrat intelligent. Cela a permis à l'attaquant de réintégrer le système pendant le processus de rachat, de manipuler l'état interne, et finalement de racheter des actifs bien supérieurs à la valeur GLP qu'il détenait réellement.
Mécanisme de rachat normal GLP
Dans GMX, GLP est un jeton de fournisseur de liquidité, représentant une part des actifs de la trésorerie (comme USDC, ETH, WBTC). Lorsque les utilisateurs appellent unstakeAndRedeemGlp, le système utilise la formule suivante pour calculer la quantité d'actifs à restituer :
La méthode de calcul de l'AUM (Actifs sous gestion) est :
AUM = valeur totale de tous les pools de tokens + pertes non réalisées globales sur les shorts - gains non réalisés globaux sur les shorts - montant réservé - déduction prédéfinie (aumDeduction)
Ce mécanisme garantit que les détenteurs de GLP reçoivent une part proportionnelle des actifs réels du trésor.
Problèmes après l'activation du levier
Lorsque enableLeverage est activé, les utilisateurs peuvent ouvrir des positions à effet de levier (longues ou courtes). Avant de racheter le GLP, un attaquant a ouvert une position courte importante sur le WBTC.
Étant donné que l'ouverture d'une position courte augmente la taille globale des positions courtes, et que le prix n'ayant pas encore changé, le système considère par défaut que cette position courte est à perte, cette perte non réalisée sera comptabilisée comme « actif » du coffre, entraînant une augmentation artificielle de l'AUM. Bien que le coffre n'ait pas réellement acquis de valeur supplémentaire, le calcul des rachats sera basé sur cet AUM gonflé, permettant ainsi à l'attaquant d'obtenir des actifs bien supérieurs à ce qu'il devrait recevoir.
Processus d'attaque
attaque de transaction
Écrit à la fin
Cette attaque a révélé de graves défauts dans le mécanisme de levier et la conception de la protection contre la réentrance de GMX. Le problème central réside dans la confiance excessive accordée à la logique de rachat d'actifs vis-à-vis de l'AUM, sans effectuer de vérifications de sécurité suffisamment prudentes sur ses composants (comme les pertes non réalisées). De plus, l'hypothèse sur l'identité de l'appelant dans les fonctions clés (EOA vs contrat) manque également de vérification obligatoire. Cet événement rappelle une fois de plus aux développeurs qu'en matière d'opérations sensibles aux fonds, il est impératif de s'assurer que l'état du système ne peut pas être manipulé, surtout lors de l'introduction de logiques financières complexes (comme le levier et les dérivés), où il est encore plus crucial de se prémunir contre les risques systémiques liés à la réentrance et à la pollution de l'état.
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.
BlockSec : Analyse du principe d'attaque de GMX
Rédaction : BlockSec
GMX a subi une attaque de hacker, avec des pertes dépassant 40 millions de dollars. Les attaquants ont exploité une vulnérabilité de réentrance et ont ouvert une position courte dans le cadre de l'activation de la fonctionnalité de levier, pour mener l'attaque.
La racine du problème réside dans l'utilisation incorrecte de la fonction executeDecreaseOrder. Le premier paramètre de cette fonction aurait dû être un compte externe (EOA), mais l'attaquant a passé une adresse de contrat intelligent. Cela a permis à l'attaquant de réintégrer le système pendant le processus de rachat, de manipuler l'état interne, et finalement de racheter des actifs bien supérieurs à la valeur GLP qu'il détenait réellement.
Mécanisme de rachat normal GLP
Dans GMX, GLP est un jeton de fournisseur de liquidité, représentant une part des actifs de la trésorerie (comme USDC, ETH, WBTC). Lorsque les utilisateurs appellent unstakeAndRedeemGlp, le système utilise la formule suivante pour calculer la quantité d'actifs à restituer :
redeem_amount = (user_GLP / total_GLP_supply) * AUM
La méthode de calcul de l'AUM (Actifs sous gestion) est :
AUM = valeur totale de tous les pools de tokens + pertes non réalisées globales sur les shorts - gains non réalisés globaux sur les shorts - montant réservé - déduction prédéfinie (aumDeduction)
Ce mécanisme garantit que les détenteurs de GLP reçoivent une part proportionnelle des actifs réels du trésor.
Problèmes après l'activation du levier
Lorsque enableLeverage est activé, les utilisateurs peuvent ouvrir des positions à effet de levier (longues ou courtes). Avant de racheter le GLP, un attaquant a ouvert une position courte importante sur le WBTC.
Étant donné que l'ouverture d'une position courte augmente la taille globale des positions courtes, et que le prix n'ayant pas encore changé, le système considère par défaut que cette position courte est à perte, cette perte non réalisée sera comptabilisée comme « actif » du coffre, entraînant une augmentation artificielle de l'AUM. Bien que le coffre n'ait pas réellement acquis de valeur supplémentaire, le calcul des rachats sera basé sur cet AUM gonflé, permettant ainsi à l'attaquant d'obtenir des actifs bien supérieurs à ce qu'il devrait recevoir.
Processus d'attaque
attaque de transaction
Écrit à la fin
Cette attaque a révélé de graves défauts dans le mécanisme de levier et la conception de la protection contre la réentrance de GMX. Le problème central réside dans la confiance excessive accordée à la logique de rachat d'actifs vis-à-vis de l'AUM, sans effectuer de vérifications de sécurité suffisamment prudentes sur ses composants (comme les pertes non réalisées). De plus, l'hypothèse sur l'identité de l'appelant dans les fonctions clés (EOA vs contrat) manque également de vérification obligatoire. Cet événement rappelle une fois de plus aux développeurs qu'en matière d'opérations sensibles aux fonds, il est impératif de s'assurer que l'état du système ne peut pas être manipulé, surtout lors de l'introduction de logiques financières complexes (comme le levier et les dérivés), où il est encore plus crucial de se prémunir contre les risques systémiques liés à la réentrance et à la pollution de l'état.