Análisis de la vulnerabilidad de desbordamiento de enteros en el módulo de seguridad de referencias de Move

Recientemente, al investigar a fondo Aptos Moveevm, descubrimos una nueva vulnerabilidad de desbordamiento de enteros. El proceso de activación de esta vulnerabilidad es bastante interesante, a continuación, analizaremos en profundidad esta vulnerabilidad y aprovecharemos la oportunidad para explorar algunos conceptos clave del lenguaje Move.

El lenguaje Move realiza una verificación de unidades de código antes de ejecutar el bytecode, y este proceso se divide en cuatro pasos. La vulnerabilidad discutida en este artículo aparece en el paso de reference_safety.

El módulo reference_safety se encarga principalmente de verificar la seguridad de las referencias en el código, incluyendo la comprobación de si existen referencias colgantes, si el acceso a referencias mutables es seguro, y si el acceso a referencias de almacenamiento global es conforme, entre otros.

Durante el proceso de verificación de seguridad, el sistema analizará cada bloque básico. Un bloque básico se refiere a una secuencia de código que no tiene instrucciones de bifurcación, excepto en la entrada y la salida. El lenguaje Move identifica bloques básicos al recorrer el código de bytes y buscar todas las instrucciones de bifurcación y secuencias de instrucciones de bucle.

El lenguaje Move admite dos tipos de referencias: referencias inmutables (&) y referencias mutables (&mut). Las referencias inmutables se utilizan para leer datos, mientras que las referencias mutables se utilizan para modificar datos. Este diseño ayuda a mejorar la seguridad y la legibilidad del código.

El proceso principal de verificación de seguridad de referencias incluye: escanear los bloques básicos en la función, analizar las instrucciones de bytecode y determinar si todas las operaciones de referencia son legales. Este proceso utiliza la estructura AbstractState, que contiene el gráfico de préstamos y los locales, asegurando conjuntamente la seguridad de las referencias en la función.

Durante el proceso de verificación, se compararán los estados antes y después de la ejecución del bloque básico (pre state y post state ), y los resultados se combinarán para actualizar el estado del bloque. Si el estado cambia y el bloque actual tiene un borde hacia atrás que apunta a sí mismo (lo que indica que hay un ciclo), se volverá a ejecutar el bloque básico hasta que el estado no cambie más o se produzca un error.

La vulnerabilidad se produce en el proceso de determinar si el resultado de join ha cambiado. Cuando la suma de la longitud de los parámetros de la función y la longitud de las variables locales excede 256, el uso del tipo u8 para representar el índice local puede provocar un desbordamiento de enteros. Aunque el lenguaje Move tiene un proceso de verificación de la cantidad de locales, solo verifica la cantidad de variables locales y no incluye la longitud de los parámetros.

Esta vulnerabilidad de desbordamiento de enteros puede provocar un ataque de denegación de servicio ( DoS ). Un atacante puede construir un bloque de código en bucle, aprovechando el desbordamiento para cambiar el estado del bloque, de modo que el nuevo mapa de locales sea diferente del anterior. Al volver a ejecutar la función execute_block, si el índice que la instrucción necesita acceder no existe en el nuevo mapa de locales de AbstractState, provocará un panic, lo que hará que todo el nodo se bloquee.

Para demostrar esta vulnerabilidad, proporcionamos un PoC que se puede reproducir en git. Este PoC contiene un bloque básico con una instrucción de salto incondicional que puede activar repetidamente las funciones execute_block y join. Al ajustar cuidadosamente los parámetros y la cantidad de variables locales, se puede reducir la longitud del nuevo mapa de locales a 8, lo que provoca un pánico en la segunda ejecución.

Esta vulnerabilidad demuestra una vez más que no hay código absolutamente seguro. A pesar de que el lenguaje Move realiza una rigurosa verificación estática antes de la ejecución, aún puede ser eludido por vulnerabilidades de desbordamiento. Esto también subraya la importancia de la auditoría de código y la necesidad de incorporar comprobaciones de seguridad en tiempo de ejecución en el diseño del lenguaje.

Como líder en la investigación de seguridad del lenguaje Move, continuaremos investigando a fondo los problemas de seguridad de Move y sugeriremos a los diseñadores del lenguaje que añadan más código de verificación en el tiempo de ejecución de Move para prevenir situaciones inesperadas. Actualmente, el lenguaje Move realiza comprobaciones de seguridad principalmente en la fase de verificación, pero creemos que esto no es suficiente. Una vez que la verificación es eludida, la falta de refuerzo de seguridad adecuado en la fase de ejecución puede llevar a problemas más graves.