Analyse approfondie de la vulnérabilité de sécurité de référence du langage Move

Récemment, lors de nos recherches approfondies sur Aptos Moveevm, nous avons découvert une nouvelle vulnérabilité d'overflow d'entier. Le processus de déclenchement de cette vulnérabilité est assez intéressant, ci-dessous nous allons l'analyser en profondeur et introduire les connaissances de base liées au langage Move. Grâce à cet article, nous croyons que les lecteurs pourront avoir une compréhension plus approfondie 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é discutée dans cet article se produit lors de l'étape reference_safety.

Le module reference_safety définit une fonction de transfert utilisée pour vérifier la sécurité des références du sujet du processus. Il vérifie principalement s'il existe des références suspendues, si l'accès aux références mutables est sûr, si l'accès aux références de stockage global est sûr, etc.

Le processus de validation commence par l'appel de la fonction d'entrée de validation de sécurité, qui appelle analyze_function. Dans analyze_function, chaque bloc de base sera validé. Un bloc de base est une séquence de code qui n'a pas d'instructions de branchement, à l'exception de l'entrée et de la sortie.

Le langage Move identifie les blocs de base en parcourant le code bytecode, cherchant toutes les instructions de branchement et les séquences d'instructions de boucle. Un exemple typique de bloc de base de code IR Move pourrait contenir 3 blocs de base, déterminés respectivement par les instructions BrTrue, Branch et Ret.

Le langage Move prend en charge deux types de références : la référence immuable (&) et la référence mutable (&mut). La référence immuable est utilisée pour lire des données, tandis que la référence mutable est utilisée pour modifier des données. Ce design aide à maintenir la sécurité du code et à identifier les modules de lecture.

Le processus principal de validation de la sécurité des références comprend : le scan des instructions de bytecode des blocs de base dans la fonction, et la vérification de la légalité de toutes les opérations de référence. Ce processus utilise la structure AbstractState, qui contient le borrow graph et les locals, pour garantir la sécurité des références dans la fonction.

Au cours du processus de validation, le code du bloc de base sera exécuté, générant l'état postérieur, puis l'état précédent et l'état postérieur seront fusionnés pour mettre à jour l'état du bloc, et les conditions postérieures de ce bloc seront propagées aux blocs suivants. Ce processus est similaire à la notion de Sea of Nodes dans V8 turbofan.

La vulnérabilité apparaît dans la fonction join_. Lorsque la somme de la longueur des paramètres et de la longueur des variables locales dépasse 256, un débordement entier se produit car local est de type u8. Bien que Move ait un processus de vérification du nombre de locals, le module de vérification des limites ne vérifie que les locals et n'inclut pas la longueur des paramètres.

Cette vulnérabilité de dépassement d'entier peut entraîner une attaque DoS. En créant un bloc de code en boucle et en exploitant le dépassement pour modifier l'état du bloc, il est possible de rendre la nouvelle carte des locaux différente de la précédente. Lors de la réexécution de la fonction execute_block, si l'index requis par l'instruction n'existe pas dans la nouvelle carte des locaux d'AbstractState, cela entraînera une DoS.

Nous avons constaté que dans le module de sécurité de référence, les opcodes MoveLoc/CopyLoc/FreeRef peuvent atteindre cet objectif. Prenons l'exemple de la fonction copy_loc, si LocalIndex n'existe pas, cela entraînera un panic, provoquant ainsi l'effondrement de l'ensemble du nœud.

Pour vérifier cette vulnérabilité, nous avons écrit un PoC. Le bloc de code dans ce PoC contient une instruction de branchement inconditionnelle qui, chaque fois que la dernière instruction est exécutée, revient à la première instruction. Par conséquent, ce bloc de code appelle plusieurs fois les fonctions execute_block et join.

En définissant des paramètres appropriés, nous pouvons faire en sorte que la longueur de la nouvelle carte locals devienne 8. Lors de la deuxième exécution de la fonction execute_block, la longueur insuffisante de locals entraînera un panic.

Cette vulnérabilité nous rappelle que même des langages mettant l'accent sur la sécurité comme Move peuvent avoir des failles. Nous conseillons aux concepteurs du langage Move d'ajouter davantage de code de vérification à l'exécution afin de prévenir des situations imprévues. Actuellement, le langage Move effectue principalement des vérifications de sécurité au stade de la vérification, mais cela pourrait ne pas suffire. Une fois la vérification contournée, si la phase d'exécution n'a pas de renforcement de sécurité suffisant, cela pourrait entraîner des problèmes plus graves.

En tant que leader de la recherche sur la sécurité du langage Move, nous continuerons à approfondir les problèmes de sécurité de Move et à partager plus de découvertes à l'avenir.