Une nouvelle vulnérabilité de débordement d'entier découverte dans le mécanisme de sécurité des références du langage Move

Récemment, lors de nos recherches approfondies sur le langage Move, nous avons découvert une nouvelle vulnérabilité d'overflow d'entier. Cette vulnérabilité se produit lors du processus de vérification de la sécurité des références, impliquant certains mécanismes clés du langage Move. En analysant cette vulnérabilité, nous pouvons mieux comprendre la conception et la mise en œuvre du langage Move.

Le processus de validation du langage Move

Le langage Move vérifie les unités de code avant d'exécuter le bytecode, ce processus se compose de 4 étapes. La vulnérabilité découverte cette fois se situe à l'étape reference_safety.

Le module reference_safety définit les fonctions de base utilisées pour vérifier la sécurité des références. Il vérifie principalement s'il existe des 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 du processus de vérification appellera analyze_function pour analyser chaque fonction. analyze_function validera chaque bloc de base dans la fonction. Un bloc de base fait référence à une séquence de code sans instructions de branchement, sauf pour l'entrée et la sortie.

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

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 module de vérification de sécurité analysera les instructions de bytecode de chaque bloc de base dans la fonction pour déterminer si toutes les opérations de référence sont légales. Le processus de vérification comprend principalement :

1. Exécuter le code du bloc de base
2. État avant et après l'exécution de la fusion
3. Mettre à jour l'état du bloc
4. Propager les conditions postérieures aux blocs suivants

Ce processus est similaire à la pensée Sea of Nodes dans le turbofan V8.

Analyse des vulnérabilités

Le problème se produit lors du processus d'état avant et après l'exécution de la fusion. Lorsque la longueur des paramètres de la fonction plus la longueur des variables locales est supérieure à 256, l'utilisation du type u8 pour représenter l'index des variables locales peut entraîner un dépassement d'entier.

Bien que le langage Move ait un processus de vérification du nombre de variables locales, cette vérification n'inclut pas la longueur des paramètres. Les développeurs semblent avoir réalisé qu'il était nécessaire de vérifier la somme des paramètres et des variables locales, mais le code réel ne vérifie que le nombre de variables locales.

Le 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 qui exploite le dépassement pour modifier l'état du bloc. Lors de la réexécution du bloc de base, si l'index requis par l'instruction n'existe pas dans le nouvel état, cela entraînera un plantage du programme.

Exploitation de vulnérabilité

Nous avons construit une preuve de concept (PoC) pour démontrer cette vulnérabilité :

1. Créez un bloc de base contenant des instructions de branchement inconditionnel pour qu'il soit exécuté plusieurs fois.
2. Définir le nombre total de paramètres et de variables locales à 264, ce qui entraîne un dépassement de la longueur de mappage des nouvelles variables locales à 8.
3. Lors de l'exécution à nouveau d'un bloc de base, tenter d'accéder à un index de variable locale inexistant provoque un panic.

Conclusion

Cette vulnérabilité prouve une fois de plus qu'il n'y a pas de code absolument sûr. Bien que le langage Move effectue une vérification statique avant l'exécution, il peut toujours être contourné par une vulnérabilité de débordement d'entier.

Pour l'avenir du développement du langage Move, nous recommandons :

1. Ajouter plus de code de vérification à l'exécution pour éviter les situations imprévues.
2. Ne vous fiez pas uniquement aux vérifications de sécurité de la phase de validation, mais renforcez également la sécurité pendant la phase d'exécution.

En tant que pionniers de la recherche sur la sécurité du langage Move, nous continuerons à approfondir les problèmes de sécurité de Move et à contribuer à son développement.