Version simplifiée : interprétation simple de la "traduction" des pro sur @CetusProtocol
Analyse des incidents de piratage :
Cette attaque révèle un problème classique de dépassement d'entier, se manifestant spécifiquement par une troncature des données lors du processus de conversion de type.
Détails techniques décomposés :
Localisation des vulnérabilités : Le problème apparaît dans le mécanisme de conversion de type de la fonction get_amount_by_liquidity, où la conversion forcée de u256 à u64 entraîne une perte de données de poids fort.
Processus d'attaque :
L'attaquant passe un paramètre de quantité de liquidité extrêmement grande via la fonction add_liquidity;
Le système appelle la fonction get_delta_b pour calculer le nombre de jetons B requis ;
3、Dans le processus de calcul, le produit de deux données de type u128 devrait théoriquement être de type u256 ;
Défaut clé : la conversion forcée du résultat u256 en u64 lors du retour de la fonction entraîne la troncature des 128 bits supérieurs.
Effet d'utilisation : Le montant de liquidité qui nécessitait à l'origine une grande quantité de jetons peut maintenant être réalisé avec une très petite quantité de jetons. Les attaquants obtiennent d'énormes parts de liquidité à un coût très faible, puis réalisent des arbitrages de fonds en détruisant une partie de la liquidité.
Analogie simple : C'est comme utiliser une calculatrice qui ne peut afficher que 8 chiffres pour calculer 1 milliard × 1 milliard, le résultat de 20 chiffres ne peut afficher que les 8 derniers chiffres, les 12 premiers disparaissent directement. L'attaquant a justement exploité cette vulnérabilité de "perte de précision de calcul".
Il est important de préciser une chose : cette vulnérabilité n'est pas liée à l'architecture de sécurité sous-jacente de @SuiNetwork, la sécurité du langage Move est temporairement encore fiable. Pourquoi ?
Le langage Move présente effectivement des avantages significatifs en matière de gestion des ressources et de sécurité des types, permettant de prévenir efficacement des problèmes de sécurité sous-jacents tels que le double paiement et les fuites de ressources. Cependant, l'erreur survenue dans le protocole Cetus concerne une erreur de calcul mathématique au niveau de la logique d'application, et non un défaut de conception du langage Move.
Plus précisément, le système de type de Move, bien que rigoureux, repose toujours sur le bon jugement du développeur pour un casting explicite. Lorsqu’un programme effectue activement une conversion de type de U256 à U64, le compilateur ne peut pas dire s’il s’agit d’une erreur intentionnelle ou d’une erreur logique.
De plus, cet incident de sécurité n'a absolument rien à voir avec le mécanisme de consensus, le traitement des transactions, la gestion des états et d'autres fonctions de base de Sui. Le réseau Sui a simplement exécuté fidèlement les instructions de transaction soumises par le protocole Cetus, et la vulnérabilité provient d'un défaut de logique dans le protocole de couche applicative lui-même.
En d'autres termes, même le langage de programmation le plus avancé ne peut pas complètement éliminer les erreurs logiques au niveau de l'application. Move peut prévenir la plupart des risques de sécurité au niveau inférieur, mais ne peut pas remplacer le développeur pour effectuer des vérifications de limites de la logique métier et des protections contre les débordements de calculs mathématiques.
Correction :
J'ai discuté davantage avec le pro, il y avait des divergences dans l'analyse technique de l'attaque par des hackers de @CetusProtocol sur certains détails, je tenais à apporter cette correction.
Précédemment, il a été correctement identifié qu'il s'agissait d'une vulnérabilité de dépassement de calcul mathématique. Les attaquants ont construit des valeurs spéciales, et la logique de "gagner gros avec peu" est correcte. La réponse aux préoccupations de tout le monde concernant la sécurité du langage Move est également correcte.
Il s'agit simplement d'avoir remarqué un phénomène d'erreur de calcul mathématique, supposant qu'il s'agit d'un problème de conversion de type, mais en réalité, il s'agit d'un problème de vérification des limites d'autres fonctions. En fait, le langage Move a un mécanisme de vérification strict pour les conversions de type, comme de u256 à u64, et ce type de conversion explicite est en effet soumis à des vérifications de sécurité dans des conditions normales.
Les emplacements spécifiques des vulnérabilités et les mécanismes de mise en œuvre technique doivent être corrigés, comme suit.
Le véritable problème survient lorsque le mécanisme de vérification de débordement de la fonction get\_delta\_a échoue :
Fonction : Calculer le nombre de tokens A nécessaires lors de l'ajout de liquidités spécifiées ;
Défaut clé : La vérification de débordement de la fonction checked\_shlw présente une erreur de codage, n'empêchant pas des valeurs de liquidité massives invalides.
Utilisation de l'attaque : les hackers construisent une valeur de liquidité spéciale, contournent la vérification d'échec et, finalement, grâce au mécanisme d'arrondi par excès de div\_round, font en sorte que le nombre de tokens A requis passe à 14).
Effet d’attaque : frappez une énorme quantité de liquidité avec 1 jeton A, puis videz le pool.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Interprétation de l'analyse du pro sur l'incident de hacking du Cetus Protocol
Version simplifiée : interprétation simple de la "traduction" des pro sur @CetusProtocol
Analyse des incidents de piratage :
Cette attaque révèle un problème classique de dépassement d'entier, se manifestant spécifiquement par une troncature des données lors du processus de conversion de type.
Détails techniques décomposés :
Localisation des vulnérabilités : Le problème apparaît dans le mécanisme de conversion de type de la fonction get_amount_by_liquidity, où la conversion forcée de u256 à u64 entraîne une perte de données de poids fort.
Processus d'attaque :
L'attaquant passe un paramètre de quantité de liquidité extrêmement grande via la fonction add_liquidity;
Le système appelle la fonction get_delta_b pour calculer le nombre de jetons B requis ;
3、Dans le processus de calcul, le produit de deux données de type u128 devrait théoriquement être de type u256 ;
Défaut clé : la conversion forcée du résultat u256 en u64 lors du retour de la fonction entraîne la troncature des 128 bits supérieurs.
Analogie simple : C'est comme utiliser une calculatrice qui ne peut afficher que 8 chiffres pour calculer 1 milliard × 1 milliard, le résultat de 20 chiffres ne peut afficher que les 8 derniers chiffres, les 12 premiers disparaissent directement. L'attaquant a justement exploité cette vulnérabilité de "perte de précision de calcul".
Il est important de préciser une chose : cette vulnérabilité n'est pas liée à l'architecture de sécurité sous-jacente de @SuiNetwork, la sécurité du langage Move est temporairement encore fiable. Pourquoi ?
Le langage Move présente effectivement des avantages significatifs en matière de gestion des ressources et de sécurité des types, permettant de prévenir efficacement des problèmes de sécurité sous-jacents tels que le double paiement et les fuites de ressources. Cependant, l'erreur survenue dans le protocole Cetus concerne une erreur de calcul mathématique au niveau de la logique d'application, et non un défaut de conception du langage Move.
Plus précisément, le système de type de Move, bien que rigoureux, repose toujours sur le bon jugement du développeur pour un casting explicite. Lorsqu’un programme effectue activement une conversion de type de U256 à U64, le compilateur ne peut pas dire s’il s’agit d’une erreur intentionnelle ou d’une erreur logique.
De plus, cet incident de sécurité n'a absolument rien à voir avec le mécanisme de consensus, le traitement des transactions, la gestion des états et d'autres fonctions de base de Sui. Le réseau Sui a simplement exécuté fidèlement les instructions de transaction soumises par le protocole Cetus, et la vulnérabilité provient d'un défaut de logique dans le protocole de couche applicative lui-même.
En d'autres termes, même le langage de programmation le plus avancé ne peut pas complètement éliminer les erreurs logiques au niveau de l'application. Move peut prévenir la plupart des risques de sécurité au niveau inférieur, mais ne peut pas remplacer le développeur pour effectuer des vérifications de limites de la logique métier et des protections contre les débordements de calculs mathématiques.
Correction :
J'ai discuté davantage avec le pro, il y avait des divergences dans l'analyse technique de l'attaque par des hackers de @CetusProtocol sur certains détails, je tenais à apporter cette correction.
Précédemment, il a été correctement identifié qu'il s'agissait d'une vulnérabilité de dépassement de calcul mathématique. Les attaquants ont construit des valeurs spéciales, et la logique de "gagner gros avec peu" est correcte. La réponse aux préoccupations de tout le monde concernant la sécurité du langage Move est également correcte.
Il s'agit simplement d'avoir remarqué un phénomène d'erreur de calcul mathématique, supposant qu'il s'agit d'un problème de conversion de type, mais en réalité, il s'agit d'un problème de vérification des limites d'autres fonctions. En fait, le langage Move a un mécanisme de vérification strict pour les conversions de type, comme de u256 à u64, et ce type de conversion explicite est en effet soumis à des vérifications de sécurité dans des conditions normales.
Les emplacements spécifiques des vulnérabilités et les mécanismes de mise en œuvre technique doivent être corrigés, comme suit.
Le véritable problème survient lorsque le mécanisme de vérification de débordement de la fonction
get\_delta\_aéchoue :Fonction : Calculer le nombre de tokens A nécessaires lors de l'ajout de liquidités spécifiées ;
Défaut clé : La vérification de débordement de la fonction
checked\_shlwprésente une erreur de codage, n'empêchant pas des valeurs de liquidité massives invalides.Utilisation de l'attaque : les hackers construisent une valeur de liquidité spéciale, contournent la vérification d'échec et, finalement, grâce au mécanisme d'arrondi par excès de
div\_round, font en sorte que le nombre de tokens A requis passe à 14).Effet d’attaque : frappez une énorme quantité de liquidité avec 1 jeton A, puis videz le pool.