GMX a subi une intrusion de hacker, entraînant une perte de plus de 40 millions de dollars. Les attaquants ont exploité une vulnérabilité de réentrance et ont établi des positions short lorsque le contrat a activé la fonction de levier pour mener l'attaque.
Le cœur du problème réside dans l'utilisation incorrecte de la fonction executeDecreaseOrder. Le premier paramètre de cette fonction devrait ê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, manipulant l'état interne, et les actifs finalement rachetés dépassent largement la valeur réelle de GLP détenue.
Dans GMX, le GLP est un jeton de fournisseur de liquidité, représentant une part des actifs du coffre (tels que USDC, ETH, WBTC). Normalement, lorsque les utilisateurs échangent leur GLP, le système calcule le montant des actifs à restituer en fonction de la proportion de GLP détenue par l'utilisateur et du montant total des actifs sous gestion (AUM) actuel. Le calcul de l'AUM inclut la valeur totale de tous les pools de jetons, les gains et pertes non réalisés des positions short globales, les montants réservés et les déductions prédéfinies, entre autres facteurs.
Cependant, lorsque la fonction de levier a été activée, un bug est apparu dans le système. L'attaquant a ouvert de grandes positions short en WBTC avant de racheter le GLP. Étant donné que l'ouverture d'une position short augmente immédiatement la taille des positions short globales, et que le prix n'a pas encore changé, le système considère par défaut que cette position short est en perte. Cette perte non réalisée a été incorrectement comptabilisée dans les "actifs" du trésor, entraînant une augmentation artificielle de l'AUM. Bien que le trésor n'ait en réalité pas obtenu de valeur supplémentaire, le calcul du rachat était basé sur cet AUM gonflé, permettant à l'attaquant d'obtenir des actifs bien supérieurs à ceux qu'il aurait dû recevoir.
Cette attaque a révélé de graves défauts dans la mécanique de levier et la conception de la protection contre les réentrées de GMX. Le problème central réside dans la confiance excessive accordée à la logique de rachat d'actifs par rapport à l'AUM, sans effectuer de vérifications de sécurité suffisamment prudentes sur ses composants (comme les pertes non réalisées). Parallèlement, l'hypothèse sur l'identité de l'appelant dans les fonctions clés (EOA vs contrat) manque également de validation obligatoire.
Cet événement rappelle aux développeurs qu'il est essentiel de s'assurer que l'état du système ne peut pas être manipulé lors d'opérations sensibles sur les fonds. En particulier, lors de l'introduction de logiques financières complexes (comme le levier et les dérivés), il est crucial de se prémunir contre les risques systémiques liés aux réentrées et à la pollution de l'état. L'équipe de développement devrait réévaluer la conception de ses contrats, renforcer les mesures de sécurité et envisager d'introduire des mécanismes de vérification d'identité et d'état plus stricts pour éviter que des attaques similaires ne se reproduisent.
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.
GMX a été attaqué par un Hacker, une vulnérabilité de réentrance a entraîné une perte de 40 millions de dollars.
GMX a subi une intrusion de hacker, entraînant une perte de plus de 40 millions de dollars. Les attaquants ont exploité une vulnérabilité de réentrance et ont établi des positions short lorsque le contrat a activé la fonction de levier pour mener l'attaque.
Le cœur du problème réside dans l'utilisation incorrecte de la fonction executeDecreaseOrder. Le premier paramètre de cette fonction devrait ê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, manipulant l'état interne, et les actifs finalement rachetés dépassent largement la valeur réelle de GLP détenue.
Dans GMX, le GLP est un jeton de fournisseur de liquidité, représentant une part des actifs du coffre (tels que USDC, ETH, WBTC). Normalement, lorsque les utilisateurs échangent leur GLP, le système calcule le montant des actifs à restituer en fonction de la proportion de GLP détenue par l'utilisateur et du montant total des actifs sous gestion (AUM) actuel. Le calcul de l'AUM inclut la valeur totale de tous les pools de jetons, les gains et pertes non réalisés des positions short globales, les montants réservés et les déductions prédéfinies, entre autres facteurs.
Cependant, lorsque la fonction de levier a été activée, un bug est apparu dans le système. L'attaquant a ouvert de grandes positions short en WBTC avant de racheter le GLP. Étant donné que l'ouverture d'une position short augmente immédiatement la taille des positions short globales, et que le prix n'a pas encore changé, le système considère par défaut que cette position short est en perte. Cette perte non réalisée a été incorrectement comptabilisée dans les "actifs" du trésor, entraînant une augmentation artificielle de l'AUM. Bien que le trésor n'ait en réalité pas obtenu de valeur supplémentaire, le calcul du rachat était basé sur cet AUM gonflé, permettant à l'attaquant d'obtenir des actifs bien supérieurs à ceux qu'il aurait dû recevoir.
Cette attaque a révélé de graves défauts dans la mécanique de levier et la conception de la protection contre les réentrées de GMX. Le problème central réside dans la confiance excessive accordée à la logique de rachat d'actifs par rapport à l'AUM, sans effectuer de vérifications de sécurité suffisamment prudentes sur ses composants (comme les pertes non réalisées). Parallèlement, l'hypothèse sur l'identité de l'appelant dans les fonctions clés (EOA vs contrat) manque également de validation obligatoire.
Cet événement rappelle aux développeurs qu'il est essentiel de s'assurer que l'état du système ne peut pas être manipulé lors d'opérations sensibles sur les fonds. En particulier, lors de l'introduction de logiques financières complexes (comme le levier et les dérivés), il est crucial de se prémunir contre les risques systémiques liés aux réentrées et à la pollution de l'état. L'équipe de développement devrait réévaluer la conception de ses contrats, renforcer les mesures de sécurité et envisager d'introduire des mécanismes de vérification d'identité et d'état plus stricts pour éviter que des attaques similaires ne se reproduisent.