Analyse des vulnérabilités de débordement d'entier dans la vérification de sécurité des références Move

Récemment, lors de nos recherches approfondies sur le langage Move, nous avons découvert une nouvelle vulnérabilité de débordement d'entier. Cette vulnérabilité existe dans le processus de vérification de la sécurité des références, et son déclenchement est assez intéressant. Cet article analysera en profondeur cette vulnérabilité et explorera certains des contextes liés au langage Move.

Le langage Move effectue une vérification des unités de code avant d'exécuter le bytecode, qui se divise en quatre étapes. Cette vulnérabilité apparaît dans l'étape de référence_safety.

Le module de validation de référence de sécurité définit une fonction de transfert utilisée pour vérifier la sécurité de référence du sujet du processus de validation. Les éléments vérifiés incluent la vérification qu'il n'y a pas de références suspendues, si l'accès aux références mutables est sûr, et si l'accès aux références de stockage global est sûr, etc.

La fonction d'entrée de vérification de sécurité cite analyze_function, qui valide chaque bloc de base. Un bloc de base se réfère à une séquence de code sans instructions de branchement, à l'exception des entrées et sorties. Le langage Move détermine les blocs de base en parcourant le bytecode, en recherchant toutes les instructions de branchement et les séquences d'instructions de boucle.

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 les données, tandis que la référence mutable est utilisée pour modifier les données. Utiliser correctement les types de références aide à maintenir la sécurité et à identifier les modules de lecture.

Le module de sécurité des références scanne les instructions de bytecode des blocs de base dans chaque fonction, vérifiant que toutes les opérations de référence sont légales. Le processus de vérification implique principalement la structure AbstractState, qui contient le graphe de prêt et les variables locales, afin d'assurer la sécurité des références dans la fonction.

Au cours du processus de validation, l'état avant et après l'exécution d'un bloc de base sera comparé, et la fusion de l'état précédent et de l'état suivant se fera en fonction de la variation de join_result. Si une variation se produit et que le bloc actuel a une arête arrière pointant vers lui-même (indiquant l'existence d'une boucle), il sautera au début de la boucle et continuera l'exécution de ce bloc de base, jusqu'à ce que l'état suivant soit égal à l'état précédent ou qu'une erreur mette fin au processus.

Le bogue se produit lors de la vérification si le résultat du join a changé. Lorsque la somme de la longueur des paramètres et de la longueur des variables locales est supérieure à 256, l'utilisation d'un type u8 pour itérer sur les locals peut entraîner un débordement d'entier. 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 des attaques par déni de service (DoS). Un attaquant peut construire un bloc de code en boucle et exploiter le dépassement pour modifier l'état du bloc, rendant la nouvelle map de locaux différente de la précédente. Lors de la réexécution de la fonction execute_block, l'analyse de la séquence d'instructions en bytes dans le bloc de base accèdera à la nouvelle map de locaux. Si l'index requis par les instructions n'existe pas dans la nouvelle map de locaux d'AbstractState, cela entraînera un DoS.

Pour vérifier cette vulnérabilité, il est possible de reproduire le PoC dans git. Le bloc de code dans le PoC contient une instruction de branchement inconditionnel qui, à chaque exécution de la dernière instruction, revient à la première instruction, entraînant plusieurs appels aux fonctions execute_block et join.

Cette vulnérabilité montre que même des langages axés sur la sécurité comme Move peuvent avoir des failles de sécurité. Elle souligne l'importance de l'audit de code et suggère également aux concepteurs du langage Move d'ajouter davantage de vérifications de code à l'exécution pour éviter des situations inattendues. Actuellement, Move effectue des vérifications de sécurité principalement à la phase de vérification, mais une fois que la validation est contournée, le manque de renforcement de la sécurité à la phase 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 problèmes de sécurité de Move et à partager davantage de découvertes par la suite.