Analyse des vulnérabilités de débordement d'entier dans le langage Move
Introduction
Après une étude approfondie de l'Aptos Moveevm, nous avons découvert une nouvelle vulnérabilité de débordement d'entier. Le processus de déclenchement de cette vulnérabilité est relativement plus intéressant, ci-dessous nous allons analyser cette vulnérabilité en profondeur et introduire quelques connaissances de base sur le langage Move. Grâce à l'explication de cet article, nous sommes convaincus que vous aurez une compréhension plus approfondie du langage Move.
Le langage Move vérifie les unités de code avant d'exécuter le bytecode. Le processus de vérification se divise en 4 étapes, et cette vulnérabilité apparaît lors de l'étape reference_safety.
Sécurité des références dans Move
Le langage Move prend en charge deux types de références : référence immuable (&) et référence mutable (&mut). La référence immuable est utilisée pour lire des données à partir de la structure, tandis que la référence mutable est utilisée pour modifier des données. Utiliser le type de référence approprié contribue à maintenir la sécurité et à identifier les modules de lecture.
Dans le module de sécurité des références de Move, les instructions de bytecode des blocs de base dans une fonction sont analysées pour vérifier la légalité de toutes les opérations de référence. Le principal processus de validation de la sécurité des références comprend l'exécution des blocs de base, la génération des états postérieurs, la fusion des états antérieurs et postérieurs, etc.
Analyse des vulnérabilités
Une vulnérabilité apparaît dans la fonction join_ qui référence le module de sécurité. Lorsque la somme de la longueur des paramètres de la fonction et de la longueur des variables locales dépasse 256, l'utilisation du type u8 pour représenter les variables locales peut entraîner un débordement entier.
Bien que Move ait un processus de vérification du nombre de locaux, le module de vérification des limites ne vérifie que les locaux et n'inclut pas la longueur des paramètres. Les développeurs semblent réaliser qu'il est nécessaire de vérifier la somme des paramètres et des valeurs locales, mais le code ne vérifie que le nombre de variables locales.
De l'overflow d'entier aux attaques DoS
En exploitant cette vulnérabilité de débordement d'entiers, un attaquant peut créer un bloc de code en boucle qui modifie l'état du bloc. Lorsqu'on exécute à nouveau la fonction execute_block, si l'index requis par l'instruction n'existe pas dans la nouvelle carte des locaux AbstractState, cela entraînera une attaque DoS.
Dans le module de référence de sécurité, des opcodes tels que MoveLoc/CopyLoc/FreeRef peuvent déclencher cette situation. Par exemple, dans la fonction copy_loc, si LocalIndex n'existe pas, cela peut provoquer un panic, entraînant ainsi l'effondrement de tout le nœud.
Reproduction de la vulnérabilité
Vous pouvez reproduire cette vulnérabilité dans git avec le code PoC suivant :
déplacer
public fun test(a: u64, b: u64, c: u64, d: u64) {
let x = 0;
boucle {
si (x == 1) {
pause
};
x = x + 1;
}
}
Les étapes pour déclencher un DoS sont les suivantes :
La première exécution de la fonction execute_block, avec parameters et locals tous deux définis sur SignatureIndex(0), a conduit à num_locals égal à 264. Après l'exécution de la fonction join_, la longueur de la nouvelle carte locals est devenue 8.
Lors de la deuxième exécution de la fonction execute_block, la première instruction du code move exécuté est copyloc(57). Comme à ce moment-là, locals n'a qu'une longueur de 8, l'offset 57 n'existe pas, ce qui entraîne un retour de None pour la fonction get(57).unwrap(), provoquant finalement un panic.
Résumé
Cette vulnérabilité indique qu'il n'y a pas de code absolument sécurisé. Bien que le langage Move effectue une vérification statique avant l'exécution du code, il peut toujours être contourné par des vulnérabilités de dépassement. Cela souligne à nouveau l'importance de l'audit de code.
Pour le langage Move, nous recommandons d'ajouter davantage de code de vérification à l'exécution pour éviter les situations inattendues. Actuellement, Move effectue principalement des vérifications de sécurité à l'étape de vérification, mais une fois que la vérification est contournée, le manque de renforcement de la sécurité à l'étape d'exécution peut entraîner des problèmes plus graves.
En tant que leader dans la recherche sur la sécurité du langage Move, nous continuerons à approfondir les questions de sécurité liées à Move et partagerons plus de découvertes par la suite.
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.
18 J'aime
Récompense
18
4
Reposter
Partager
Commentaire
0/400
PretendingToReadDocs
· 08-15 17:34
move même un bull cela pose problème
Voir l'originalRépondre0
WalletDetective
· 08-14 07:06
Après y avoir réfléchi, cette vulnérabilité a quelque chose d'intéressant.
Voir l'originalRépondre0
ponzi_poet
· 08-14 07:00
Est-ce sincère ou juste pour faire de l'argent, le débordement de move.
Voir l'originalRépondre0
ForkTongue
· 08-14 06:52
Vous continuez à écrire des bugs de sécurité, n'est-ce pas ?
Analyse de la vulnérabilité du débordement d'entiers dans le langage Move : de la sécurité des références à l'attaque par déni de service (DoS)
Analyse des vulnérabilités de débordement d'entier dans le langage Move
Introduction
Après une étude approfondie de l'Aptos Moveevm, nous avons découvert une nouvelle vulnérabilité de débordement d'entier. Le processus de déclenchement de cette vulnérabilité est relativement plus intéressant, ci-dessous nous allons analyser cette vulnérabilité en profondeur et introduire quelques connaissances de base sur le langage Move. Grâce à l'explication de cet article, nous sommes convaincus que vous aurez une compréhension plus approfondie du langage Move.
Le langage Move vérifie les unités de code avant d'exécuter le bytecode. Le processus de vérification se divise en 4 étapes, et cette vulnérabilité apparaît lors de l'étape reference_safety.
Sécurité des références dans Move
Le langage Move prend en charge deux types de références : référence immuable (&) et référence mutable (&mut). La référence immuable est utilisée pour lire des données à partir de la structure, tandis que la référence mutable est utilisée pour modifier des données. Utiliser le type de référence approprié contribue à maintenir la sécurité et à identifier les modules de lecture.
Dans le module de sécurité des références de Move, les instructions de bytecode des blocs de base dans une fonction sont analysées pour vérifier la légalité de toutes les opérations de référence. Le principal processus de validation de la sécurité des références comprend l'exécution des blocs de base, la génération des états postérieurs, la fusion des états antérieurs et postérieurs, etc.
Analyse des vulnérabilités
Une vulnérabilité apparaît dans la fonction join_ qui référence le module de sécurité. Lorsque la somme de la longueur des paramètres de la fonction et de la longueur des variables locales dépasse 256, l'utilisation du type u8 pour représenter les variables locales peut entraîner un débordement entier.
Bien que Move ait un processus de vérification du nombre de locaux, le module de vérification des limites ne vérifie que les locaux et n'inclut pas la longueur des paramètres. Les développeurs semblent réaliser qu'il est nécessaire de vérifier la somme des paramètres et des valeurs locales, mais le code ne vérifie que le nombre de variables locales.
De l'overflow d'entier aux attaques DoS
En exploitant cette vulnérabilité de débordement d'entiers, un attaquant peut créer un bloc de code en boucle qui modifie l'état du bloc. Lorsqu'on exécute à nouveau la fonction execute_block, si l'index requis par l'instruction n'existe pas dans la nouvelle carte des locaux AbstractState, cela entraînera une attaque DoS.
Dans le module de référence de sécurité, des opcodes tels que MoveLoc/CopyLoc/FreeRef peuvent déclencher cette situation. Par exemple, dans la fonction copy_loc, si LocalIndex n'existe pas, cela peut provoquer un panic, entraînant ainsi l'effondrement de tout le nœud.
Reproduction de la vulnérabilité
Vous pouvez reproduire cette vulnérabilité dans git avec le code PoC suivant :
déplacer public fun test(a: u64, b: u64, c: u64, d: u64) { let x = 0; boucle { si (x == 1) { pause }; x = x + 1; } }
Les étapes pour déclencher un DoS sont les suivantes :
La première exécution de la fonction execute_block, avec parameters et locals tous deux définis sur SignatureIndex(0), a conduit à num_locals égal à 264. Après l'exécution de la fonction join_, la longueur de la nouvelle carte locals est devenue 8.
Lors de la deuxième exécution de la fonction execute_block, la première instruction du code move exécuté est copyloc(57). Comme à ce moment-là, locals n'a qu'une longueur de 8, l'offset 57 n'existe pas, ce qui entraîne un retour de None pour la fonction get(57).unwrap(), provoquant finalement un panic.
Résumé
Cette vulnérabilité indique qu'il n'y a pas de code absolument sécurisé. Bien que le langage Move effectue une vérification statique avant l'exécution du code, il peut toujours être contourné par des vulnérabilités de dépassement. Cela souligne à nouveau l'importance de l'audit de code.
Pour le langage Move, nous recommandons d'ajouter davantage de code de vérification à l'exécution pour éviter les situations inattendues. Actuellement, Move effectue principalement des vérifications de sécurité à l'étape de vérification, mais une fois que la vérification est contournée, le manque de renforcement de la sécurité à l'étape d'exécution peut entraîner des problèmes plus graves.
En tant que leader dans la recherche sur la sécurité du langage Move, nous continuerons à approfondir les questions de sécurité liées à Move et partagerons plus de découvertes par la suite.