Analyse de la vulnérabilité de dépassement d'entier dans la vérification de sécurité des références du langage Move
Récemment, des chercheurs ont découvert une nouvelle vulnérabilité de débordement d'entier lors de l'analyse approfondie de l'Aptos Moveevm. Cette vulnérabilité existe dans le processus de vérification de la sécurité des références du langage Move, impliquant spécifiquement l'étape reference_safety. Cet article explorera en profondeur cette vulnérabilité et expliquera son processus de déclenchement ainsi que ses impacts potentiels.
Le processus de validation du langage Move
Le langage Move effectue une validation des unités de code avant l'exécution du bytecode, ce processus se décompose en 4 étapes. La vulnérabilité découverte cette fois-ci se situe dans l'étape reference_safety. Cette étape est principalement utilisée pour vérifier la sécurité des références, y compris la vérification de l'existence de références pendantes, la sécurité d'accès aux références mutables, la sécurité d'accès aux références de stockage global, etc.
Le processus de validation commence par l'identification des blocs de base. Dans le langage Move, les blocs de base sont déterminés en parcourant le bytecode et en recherchant toutes les séquences d'instructions de branchement et d'instructions de boucle. Chaque bloc de base est une séquence de code sans instructions de branchement, à l'exception des entrées et sorties.
Mécanisme de vérification de sécurité des citations
Le langage Move prend en charge deux types de références : les références immuables (&) et les références mutables (&mut). Le module de vérification de la sécurité des références scanne le code byte des blocs de base de chaque fonction pour déterminer si toutes les opérations de référence sont légales.
Le processus de validation utilise la structure AbstractState pour représenter l'état, comprenant deux composants clés : le graphe d'emprunt et les locaux. Lors de la validation, les changements d'état avant et après l'exécution des blocs de base sont comparés, et les résultats sont propagés aux blocs suivants.
Détails de la vulnérabilité
Le bug se trouve dans la fonction join_. Cette fonction est utilisée pour fusionner l'état avant et après l'exécution des blocs de base. Le problème vient de la méthode iter_locals(), qui renvoie un itérateur de type u8. Lorsque la somme de la longueur des paramètres de la fonction et de la longueur des variables locales dépasse 256, cela entraîne un débordement d'entier.
Bien que le langage Move ait un processus de vérification du nombre de locaux, il ne vérifie que le nombre de variables locales et n'inclut pas la longueur des paramètres. Cela pourrait être une négligence des développeurs.
Exploitation des vulnérabilités et impact
En exploitant cette vulnérabilité de débordement d'entier, un attaquant peut construire des blocs de code de boucle spéciaux qui modifient l'état du bloc. Lorsque le bloc de base est exécuté à nouveau, si l'index accédé par l'instruction n'existe pas dans la nouvelle carte des locaux, cela entraînera un déni de service (DoS).
Plus précisément, dans le module de référence de sécurité, des opcodes tels que MoveLoc/CopyLoc/FreeRef peuvent provoquer un panic en raison de l'accès à un LocalIndex inexistant, entraînant ainsi le plantage de l'ensemble du nœud.
Résumé et recommandations
Cette vulnérabilité prouve une fois de plus que même les langages soigneusement conçus peuvent présenter des risques de sécurité. Pour le langage Move, nous recommandons :
Renforcer l'audit de code pour éviter des négligences similaires.
Ajouter plus de code de vérification lors de l'exécution de Move, ne pas se fier uniquement aux vérifications de sécurité de la phase de validation.
Ajouter des mesures de renforcement de la sécurité pendant la phase d'exécution pour empêcher que la validation soit contournée, ce qui pourrait entraîner des problèmes plus graves.
En tant que pionniers de la recherche sur la sécurité du langage Move, nous continuerons à explorer en profondeur les problèmes de sécurité connexes, contribuant ainsi au développement sain de l'écosystème Move.
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.
21 J'aime
Récompense
21
9
Partager
Commentaire
0/400
LiquidationWatcher
· 07-07 17:46
omg une autre exploitation defi... ça me rappelle de gros souvenirs de 2022 rn
Voir l'originalRépondre0
BearMarketSunriser
· 07-07 02:16
move condamné ah, trader a n'est même pas aussi bon que trader b
Voir l'originalRépondre0
SundayDegen
· 07-06 08:36
Eh bien, ce bug est effectivement un peu basique.
Voir l'originalRépondre0
MoonRocketman
· 07-05 04:47
La hauteur d'interception de Move à 256 a échoué, attention au risque de crash de la fusée.
Voir l'originalRépondre0
Web3ProductManager
· 07-05 04:47
en regardant les données du tunnel de conversion, ce bug de débordement = une friction majeure dans l'ux pour être honnête
Analyse de la vulnérabilité de débordement d'entier par vérification de sécurité dans le langage Move
Analyse de la vulnérabilité de dépassement d'entier dans la vérification de sécurité des références du langage Move
Récemment, des chercheurs ont découvert une nouvelle vulnérabilité de débordement d'entier lors de l'analyse approfondie de l'Aptos Moveevm. Cette vulnérabilité existe dans le processus de vérification de la sécurité des références du langage Move, impliquant spécifiquement l'étape reference_safety. Cet article explorera en profondeur cette vulnérabilité et expliquera son processus de déclenchement ainsi que ses impacts potentiels.
Le processus de validation du langage Move
Le langage Move effectue une validation des unités de code avant l'exécution du bytecode, ce processus se décompose en 4 étapes. La vulnérabilité découverte cette fois-ci se situe dans l'étape reference_safety. Cette étape est principalement utilisée pour vérifier la sécurité des références, y compris la vérification de l'existence de références pendantes, la sécurité d'accès aux références mutables, la sécurité d'accès aux références de stockage global, etc.
Le processus de validation commence par l'identification des blocs de base. Dans le langage Move, les blocs de base sont déterminés en parcourant le bytecode et en recherchant toutes les séquences d'instructions de branchement et d'instructions de boucle. Chaque bloc de base est une séquence de code sans instructions de branchement, à l'exception des entrées et sorties.
Mécanisme de vérification de sécurité des citations
Le langage Move prend en charge deux types de références : les références immuables (&) et les références mutables (&mut). Le module de vérification de la sécurité des références scanne le code byte des blocs de base de chaque fonction pour déterminer si toutes les opérations de référence sont légales.
Le processus de validation utilise la structure AbstractState pour représenter l'état, comprenant deux composants clés : le graphe d'emprunt et les locaux. Lors de la validation, les changements d'état avant et après l'exécution des blocs de base sont comparés, et les résultats sont propagés aux blocs suivants.
Détails de la vulnérabilité
Le bug se trouve dans la fonction join_. Cette fonction est utilisée pour fusionner l'état avant et après l'exécution des blocs de base. Le problème vient de la méthode iter_locals(), qui renvoie un itérateur de type u8. Lorsque la somme de la longueur des paramètres de la fonction et de la longueur des variables locales dépasse 256, cela entraîne un débordement d'entier.
Bien que le langage Move ait un processus de vérification du nombre de locaux, il ne vérifie que le nombre de variables locales et n'inclut pas la longueur des paramètres. Cela pourrait être une négligence des développeurs.
Exploitation des vulnérabilités et impact
En exploitant cette vulnérabilité de débordement d'entier, un attaquant peut construire des blocs de code de boucle spéciaux qui modifient l'état du bloc. Lorsque le bloc de base est exécuté à nouveau, si l'index accédé par l'instruction n'existe pas dans la nouvelle carte des locaux, cela entraînera un déni de service (DoS).
Plus précisément, dans le module de référence de sécurité, des opcodes tels que MoveLoc/CopyLoc/FreeRef peuvent provoquer un panic en raison de l'accès à un LocalIndex inexistant, entraînant ainsi le plantage de l'ensemble du nœud.
Résumé et recommandations
Cette vulnérabilité prouve une fois de plus que même les langages soigneusement conçus peuvent présenter des risques de sécurité. Pour le langage Move, nous recommandons :
En tant que pionniers de la recherche sur la sécurité du langage Move, nous continuerons à explorer en profondeur les problèmes de sécurité connexes, contribuant ainsi au développement sain de l'écosystème Move.