Analyse des vulnérabilités de débordement d'entiers dans le module de sécurité de référence Move

Récemment, nous avons découvert une nouvelle vulnérabilité de débordement d’entier en creusant plus profondément dans l’Aptos Moveevm. Il est assez intéressant de voir comment cette vulnérabilité est déclenchée, nous allons donc l’examiner de plus près et profiter de l’occasion pour explorer certains des concepts de base du langage Move.

Le langage Move effectue une vérification des unités de code avant d'exécuter le bytecode, ce processus se divise en quatre étapes. La vulnérabilité discutée dans cet article survient lors de l'étape de reference_safety.

Le module reference_safety est principalement responsable de la vérification de la sécurité des références dans le code, y compris la vérification de l'existence de références pendantes, la sécurité d'accès aux références mutables et la conformité des accès aux références de stockage global.

Dans le processus de validation de sécurité, le système analysera chaque bloc de base. Un bloc de base est une séquence de code sans instructions de branchement, à l'exception des entrées et des sorties. Le langage Move identifie les blocs de base en parcourant le bytecode et 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. Ce design contribue à améliorer la sécurité et la lisibilité du code.

Le processus principal de la vérification de la sécurité des références comprend : l'analyse des blocs de base dans la fonction, l'analyse des instructions de bytecode, et la détermination de la légalité de toutes les opérations de référence. Ce processus utilise la structure AbstractState, qui contient le graphe de prêt et les locaux, garantissant ensemble la sécurité des références dans la fonction.

Le processus de vérification comparera l'état avant et après l'exécution du bloc de base (pre state et post state), et fusionnera les résultats pour mettre à jour l'état du bloc. Si l'état change et que le bloc actuel a une arête rétroactive pointant vers lui-même (indiquant une boucle), le bloc de base sera réexécuté jusqu'à ce que l'état ne change plus ou qu'une erreur se produise.

Le bogue se produit lors de la vérification si le résultat de la jointure a changé. 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 l'index local peut entraîner 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.

Cette vulnérabilité de dépassement d'entier peut entraîner une attaque par déni de service ( DoS ). Un attaquant peut construire un bloc de code en boucle, exploitant le dépassement pour modifier l'état du bloc, rendant la nouvelle carte locals différente de la précédente. Lorsqu'on exécute à nouveau la fonction execute_block, si l'index requis par les instructions n'existe pas dans la nouvelle carte locals d'AbstractState, cela provoquera un panic, faisant ainsi planter l'ensemble du nœud.

Pour démontrer cette vulnérabilité, nous avons fourni un PoC qui peut être reproduit dans git. Ce PoC contient un bloc de base avec une instruction de branchement inconditionnelle, pouvant déclencher plusieurs fois les fonctions execute_block et join. En ajustant soigneusement le nombre de paramètres et de variables locales, il est possible de réduire la longueur de la nouvelle map locals à 8, puis de déclencher un panic lors de la deuxième exécution.

Cette vulnérabilité prouve à nouveau qu'il n'existe pas de code absolument sécurisé. Bien que le langage Move ait subi des vérifications statiques strictes avant l'exécution, il peut toujours être contourné par des vulnérabilités de dépassement. Cela souligne également l'importance de l'audit de code et la nécessité d'ajouter des vérifications de sécurité à l'exécution dans la conception des langages.

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 à recommander aux concepteurs du langage d'ajouter davantage de code de vérification dans l'exécution de Move pour prévenir les situations inattendues. Actuellement, le langage Move effectue principalement des vérifications de sécurité à l'étape de vérification, mais nous pensons que cela n'est pas suffisant. Une fois que la vérification a été contournée, le manque de renforcement de la sécurité à l'étape d'exécution peut entraîner des problèmes plus graves.