Analyse des vulnérabilités de débordement d'entiers dans le langage Move

Après une étude approfondie du langage Move, nous avons découvert une nouvelle vulnérabilité de débordement d'entier. Cette vulnérabilité se produit lors de la phase de vérification de la sécurité des références dans le processus de validation du bytecode du langage Move. Cet article analysera en détail le processus de déclenchement de cette vulnérabilité et explorera certains concepts clés du langage Move.

Processus de vérification des octets de code du langage Move

Le langage Move effectue une validation du code avant d'exécuter le bytecode, et cela se divise en 4 étapes. La vulnérabilité actuelle se situe dans l'étape reference_safety. Cette étape est principalement responsable de la vérification de la sécurité des références, y compris la vérification de l'existence de références pendantes et la sécurité d'accès aux références mutables, etc.

Le processus de vérification commence par l'identification des blocs de code. Un bloc de code se réfère à une séquence de code sans instructions de branchement, à l'exception des entrées et sorties. Move détermine les blocs de code en parcourant le bytecode, en recherchant toutes les instructions de branchement et les instructions de boucle.

Sécurité des références dans Move

Move prend en charge deux types de références : référence immuable (&) et référence mutable (&mut). Le module de sécurité des références examinera les instructions de bytecode de chaque bloc de base dans la fonction, vérifiant que toutes les opérations de référence sont légales.

Le processus de validation utilise la structure AbstractState pour représenter l'état, qui comprend le graphique de prêt et les locaux. Lors de la validation, les états avant et après l'exécution sont comparés et l'état du bloc est mis à jour.

Analyse des vulnérabilités

Le bogue se trouve dans la fonction join_. Cette fonction est utilisée pour fusionner l'état avant et après l'exécution, en mettant à jour la carte locals et le graphe des emprunts. Le problème réside dans le fait que l'itérateur locals retourne un type u8, ce qui provoque un débordement lorsque la somme de la longueur des paramètres et de la longueur des variables locales dépasse 256.

Bien que Move ait un processus de vérification du nombre de locals, il ne vérifie que le nombre de variables locales et n'inclut pas la longueur des paramètres.

Exploitation de vulnérabilité

L'utilisation de ce débordement peut modifier l'état du bloc de base. Dans le code en boucle, chaque fois que le bloc de base est exécuté, l'état change. Lorsqu'il est exécuté à nouveau, si l'index accédé par l'instruction n'existe pas dans la nouvelle carte des locaux, cela provoquera une panique, permettant ainsi une attaque DoS.

Démonstration PoC

Un code PoC reproductible a été fourni, en déclenchant un dépassement d'entier en définissant des paramètres spécifiques et un nombre de variables locales, ce qui entraîne un plantage du programme.

Résumé

Cette faille prouve une fois de plus l'importance de l'audit de code. Pour le langage Move, il est conseillé d'ajouter davantage de vérifications de sécurité à l'exécution, et de ne pas se fier uniquement aux vérifications de la phase de validation. Nous continuerons à approfondir les questions de sécurité liées au langage Move et à contribuer à son développement.