Análisis de vulnerabilidades de desbordamiento de enteros en el lenguaje Move
Introducción
Después de investigar a fondo Aptos Moveevm, hemos descubierto una nueva vulnerabilidad de desbordamiento de enteros. El proceso para activar esta vulnerabilidad es relativamente más interesante; a continuación, realizaremos un análisis detallado de esta vulnerabilidad e introduciremos algunos conocimientos básicos sobre el lenguaje Move. A través de la explicación de este artículo, estamos seguros de que tendrás una comprensión más profunda del lenguaje Move.
El lenguaje Move valida las unidades de código antes de ejecutar el bytecode. El proceso de validación se divide en 4 pasos, y esta vulnerabilidad aparece en el paso de reference_safety.
Seguridad de referencias en Move
El lenguaje Move admite dos tipos de referencias: referencia inmutable (&) y referencia mutable (&mut). La referencia inmutable se utiliza para leer datos de una estructura, mientras que la referencia mutable se utiliza para modificar datos. Usar el tipo de referencia adecuado ayuda a mantener la seguridad y a identificar el módulo de lectura.
En el módulo de seguridad de referencias de Move, se escanearán las instrucciones de bytecode de los bloques básicos de la función para verificar la legalidad de todas las operaciones de referencia. El proceso principal para validar la seguridad de referencias incluye la ejecución de bloques básicos, la generación de estados posteriores, la fusión de estados anteriores y posteriores, entre otros pasos.
Análisis de vulnerabilidades
La vulnerabilidad se encuentra en la función join_ que hace referencia al módulo de seguridad. Cuando la suma de la longitud de los parámetros de la función y la longitud de las variables locales es mayor a 256, el uso del tipo u8 para representar las variables locales puede provocar un desbordamiento de enteros.
Aunque Move tiene un proceso para verificar el número de locals, en el módulo de check bounds solo se verificaron los locals y no se incluyó la longitud de los parámetros. Los desarrolladores parecen haberse dado cuenta de que es necesario verificar la suma total de parámetros y valores locales, pero en el código solo se verificó el número de variables locales.
De desbordamiento de enteros a ataques DoS
Aprovechando esta vulnerabilidad de desbordamiento de enteros, un atacante puede crear un bloque de código en bucle que cambie el estado del bloque. Cuando se ejecute nuevamente la función execute_block, si el índice que necesita acceder a la instrucción no existe en el nuevo mapa de locales de AbstractState, se producirá un ataque DoS.
En el módulo de referencia de seguridad, los códigos de operación como MoveLoc/CopyLoc/FreeRef pueden desencadenar esta situación. Por ejemplo, en la función copy_loc, si LocalIndex no existe, provocará un panic, lo que a su vez causará que todo el nodo se bloquee.
Reproducción de vulnerabilidades
Se puede reproducir esta vulnerabilidad en git utilizando el siguiente código PoC:
mover
public fun test(a: u64, b: u64, c: u64, d: u64) {
let x = 0;
bucle {
si (x == 1) {
romper
};
x = x + 1;
}
}
Los pasos para activar un DoS son los siguientes:
La primera vez que se ejecuta la función execute_block, se establecen parameters y locals ambos como SignatureIndex(0), lo que provoca que num_locals sea 264. Después de ejecutar la función join_, la nueva longitud del mapa locals se convierte en 8.
La segunda vez que se ejecuta la función execute_block, se ejecuta la primera instrucción del código move copyloc(57). Dado que en este momento locals solo tiene una longitud de 8, el offset 57 no existe, lo que provoca que la función get(57).unwrap() devuelva None, lo que finalmente provoca un panic.
Resumen
Esta vulnerabilidad indica que no hay código absolutamente seguro. Aunque el lenguaje Move realiza una verificación estática antes de la ejecución del código, aún puede ser eludido por vulnerabilidades de desbordamiento. Esto enfatiza nuevamente la importancia de la auditoría de código.
Para el lenguaje Move, recomendamos agregar más código de verificación en tiempo de ejecución para prevenir situaciones inesperadas. Actualmente, Move realiza verificaciones de seguridad principalmente en la etapa de verificación, pero una vez que se elude la verificación, la falta de refuerzo de seguridad suficiente en la etapa de ejecución puede llevar a problemas más graves.
Como líderes en la investigación de seguridad del lenguaje Move, continuaremos profundizando en los problemas de seguridad de Move y compartiremos más descubrimientos en el futuro.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
16 me gusta
Recompensa
16
4
Republicar
Compartir
Comentar
0/400
PretendingToReadDocs
· hace12h
move ya sea alcista esto también tiene problemas
Ver originalesResponder0
WalletDetective
· 08-14 07:06
Al examinarlo detenidamente, esta vulnerabilidad tiene su miga.
Ver originalesResponder0
ponzi_poet
· 08-14 07:00
¿Es sincero o solo busca hacer dinero? move desbordamiento
Análisis de la vulnerabilidad de desbordamiento de enteros en el lenguaje Move: de la seguridad de referencia al ataque DoS
Análisis de vulnerabilidades de desbordamiento de enteros en el lenguaje Move
Introducción
Después de investigar a fondo Aptos Moveevm, hemos descubierto una nueva vulnerabilidad de desbordamiento de enteros. El proceso para activar esta vulnerabilidad es relativamente más interesante; a continuación, realizaremos un análisis detallado de esta vulnerabilidad e introduciremos algunos conocimientos básicos sobre el lenguaje Move. A través de la explicación de este artículo, estamos seguros de que tendrás una comprensión más profunda del lenguaje Move.
El lenguaje Move valida las unidades de código antes de ejecutar el bytecode. El proceso de validación se divide en 4 pasos, y esta vulnerabilidad aparece en el paso de reference_safety.
Seguridad de referencias en Move
El lenguaje Move admite dos tipos de referencias: referencia inmutable (&) y referencia mutable (&mut). La referencia inmutable se utiliza para leer datos de una estructura, mientras que la referencia mutable se utiliza para modificar datos. Usar el tipo de referencia adecuado ayuda a mantener la seguridad y a identificar el módulo de lectura.
En el módulo de seguridad de referencias de Move, se escanearán las instrucciones de bytecode de los bloques básicos de la función para verificar la legalidad de todas las operaciones de referencia. El proceso principal para validar la seguridad de referencias incluye la ejecución de bloques básicos, la generación de estados posteriores, la fusión de estados anteriores y posteriores, entre otros pasos.
Análisis de vulnerabilidades
La vulnerabilidad se encuentra en la función join_ que hace referencia al módulo de seguridad. Cuando la suma de la longitud de los parámetros de la función y la longitud de las variables locales es mayor a 256, el uso del tipo u8 para representar las variables locales puede provocar un desbordamiento de enteros.
Aunque Move tiene un proceso para verificar el número de locals, en el módulo de check bounds solo se verificaron los locals y no se incluyó la longitud de los parámetros. Los desarrolladores parecen haberse dado cuenta de que es necesario verificar la suma total de parámetros y valores locales, pero en el código solo se verificó el número de variables locales.
De desbordamiento de enteros a ataques DoS
Aprovechando esta vulnerabilidad de desbordamiento de enteros, un atacante puede crear un bloque de código en bucle que cambie el estado del bloque. Cuando se ejecute nuevamente la función execute_block, si el índice que necesita acceder a la instrucción no existe en el nuevo mapa de locales de AbstractState, se producirá un ataque DoS.
En el módulo de referencia de seguridad, los códigos de operación como MoveLoc/CopyLoc/FreeRef pueden desencadenar esta situación. Por ejemplo, en la función copy_loc, si LocalIndex no existe, provocará un panic, lo que a su vez causará que todo el nodo se bloquee.
Reproducción de vulnerabilidades
Se puede reproducir esta vulnerabilidad en git utilizando el siguiente código PoC:
mover public fun test(a: u64, b: u64, c: u64, d: u64) { let x = 0; bucle { si (x == 1) { romper }; x = x + 1; } }
Los pasos para activar un DoS son los siguientes:
La primera vez que se ejecuta la función execute_block, se establecen parameters y locals ambos como SignatureIndex(0), lo que provoca que num_locals sea 264. Después de ejecutar la función join_, la nueva longitud del mapa locals se convierte en 8.
La segunda vez que se ejecuta la función execute_block, se ejecuta la primera instrucción del código move copyloc(57). Dado que en este momento locals solo tiene una longitud de 8, el offset 57 no existe, lo que provoca que la función get(57).unwrap() devuelva None, lo que finalmente provoca un panic.
Resumen
Esta vulnerabilidad indica que no hay código absolutamente seguro. Aunque el lenguaje Move realiza una verificación estática antes de la ejecución del código, aún puede ser eludido por vulnerabilidades de desbordamiento. Esto enfatiza nuevamente la importancia de la auditoría de código.
Para el lenguaje Move, recomendamos agregar más código de verificación en tiempo de ejecución para prevenir situaciones inesperadas. Actualmente, Move realiza verificaciones de seguridad principalmente en la etapa de verificación, pero una vez que se elude la verificación, la falta de refuerzo de seguridad suficiente en la etapa de ejecución puede llevar a problemas más graves.
Como líderes en la investigación de seguridad del lenguaje Move, continuaremos profundizando en los problemas de seguridad de Move y compartiremos más descubrimientos en el futuro.