Análisis de vulnerabilidades por desbordamiento de enteros en la verificación de seguridad de referencias del lenguaje Move
Recientemente, al realizar una investigación profunda sobre el lenguaje Move, descubrimos una nueva vulnerabilidad de desbordamiento de enteros. Esta vulnerabilidad existe en el proceso de verificación de seguridad de referencias, y su proceso de activación es bastante interesante. Este artículo realizará un análisis profundo de esta vulnerabilidad y explorará algunos conocimientos de fondo relacionados con el lenguaje Move.
El lenguaje Move realiza una verificación de unidades de código antes de ejecutar el bytecode, que se divide en cuatro pasos. Esta vulnerabilidad aparece en el paso de reference_safety.
El módulo de verificación de referencias de seguridad define una función de transferencia utilizada para verificar la seguridad de referencia del sujeto del proceso. Los contenidos de la verificación incluyen comprobar que no haya referencias colgantes, si el acceso a las referencias mutables es seguro, si el acceso a las referencias de almacenamiento global es seguro, etc.
La función de entrada de verificación de seguridad llamada analyze_function valida 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 determina los bloques básicos al recorrer el bytecode y buscar todas las instrucciones de bifurcación y secuencias de instrucciones de bucle.
El lenguaje Move admite dos tipos de referencias: referencia inmutable & y referencia mutable &mut. Las referencias inmutables se utilizan para leer datos, mientras que las referencias mutables se utilizan para modificar datos. Usar correctamente los tipos de referencia ayuda a mantener la seguridad y a identificar los módulos de lectura.
El módulo de seguridad de referencias escaneará las instrucciones de bytes de los bloques básicos de la función por unidad de función, verificando que todas las operaciones de referencia sean legales. El proceso de verificación implica principalmente la estructura AbstractState, que incluye el gráfico de préstamos y las variables locales, para garantizar la seguridad de las referencias dentro de la función.
Durante el proceso de verificación, se comparará el estado antes y después de la ejecución del bloque básico, y se fusionarán el estado anterior y el estado posterior según si ha cambiado el join_result. Si hay un cambio y el bloque actual tiene un borde hacia atrás que apunta a sí mismo (lo que indica un bucle), se volverá al inicio del bucle y se continuará ejecutando el bloque básico hasta que el estado posterior sea igual al estado anterior o se interrumpa debido a un error.
Se produce una vulnerabilidad en el proceso de determinar si el resultado de join ha cambiado. Cuando la suma de la longitud de los parámetros y la longitud de la variable local es mayor que 256, el uso de la iteración de tipo u8 sobre locals puede provocar un desbordamiento de enteros. Aunque Move tiene un proceso para comprobar el número de locals, el módulo de verificación de límites solo revisa los locals y no incluye la longitud de los parámetros.
Esta vulnerabilidad de desbordamiento de enteros puede provocar ataques de denegación de servicio (DoS). Un atacante puede construir un bloque de código en bucle y aprovechar el desbordamiento para cambiar el estado del bloque, haciendo que el nuevo mapa de locales sea diferente al anterior. Al volver a ejecutar la función execute_block, el análisis de la secuencia de instrucciones de bytecode en el bloque básico accederá al nuevo mapa de locales. Si el índice que necesita ser accedido por las instrucciones no existe en el nuevo mapa de locales de AbstractState, provocará un DoS.
Para verificar esta vulnerabilidad, se puede reproducir el PoC en git. El bloque de código en el PoC contiene una instrucción de salto incondicional que, al ejecutar la última instrucción, salta de nuevo a la primera instrucción, lo que provoca múltiples llamadas a las funciones execute_block y join.
Esta vulnerabilidad indica que incluso lenguajes enfocados en la seguridad como Move pueden tener riesgos de seguridad. Resalta la importancia de la auditoría de código y sugiere a los diseñadores del lenguaje Move que incorporen más comprobaciones de código en tiempo de ejecución para prevenir situaciones inesperadas. Actualmente, Move realiza comprobaciones de seguridad principalmente en la fase de verificación, pero una vez que se elude la verificación, la falta de un reforzamiento de seguridad adecuado en la fase de ejecución puede resultar en 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 hallazgos 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.
20 me gusta
Recompensa
20
6
Compartir
Comentar
0/400
BagHolderTillRetire
· 07-22 09:41
Este bug es increíble, desbordamiento que causa un colapso.
Ver originalesResponder0
MetaverseVagabond
· 07-21 19:40
El error de desbordamiento ha vuelto, qué desastre.
Ver originalesResponder0
HeavenAndEarthAreBle
· 07-20 02:27
A la madre que la parió
Ver originalesResponder0
MemeTokenGenius
· 07-20 00:50
Ay, este bug realmente explotó.
Ver originalesResponder0
GamefiHarvester
· 07-20 00:43
¿Todavía no lo han reparado a tiempo? Los tontos de hierro están esperando a que los tomen por tontos.
Se ha encontrado una nueva vulnerabilidad de desbordamiento de enteros en la verificación de seguridad de referencias en el lenguaje Move.
Análisis de vulnerabilidades por desbordamiento de enteros en la verificación de seguridad de referencias del lenguaje Move
Recientemente, al realizar una investigación profunda sobre el lenguaje Move, descubrimos una nueva vulnerabilidad de desbordamiento de enteros. Esta vulnerabilidad existe en el proceso de verificación de seguridad de referencias, y su proceso de activación es bastante interesante. Este artículo realizará un análisis profundo de esta vulnerabilidad y explorará algunos conocimientos de fondo relacionados con el lenguaje Move.
El lenguaje Move realiza una verificación de unidades de código antes de ejecutar el bytecode, que se divide en cuatro pasos. Esta vulnerabilidad aparece en el paso de reference_safety.
El módulo de verificación de referencias de seguridad define una función de transferencia utilizada para verificar la seguridad de referencia del sujeto del proceso. Los contenidos de la verificación incluyen comprobar que no haya referencias colgantes, si el acceso a las referencias mutables es seguro, si el acceso a las referencias de almacenamiento global es seguro, etc.
La función de entrada de verificación de seguridad llamada analyze_function valida 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 determina los bloques básicos al recorrer el bytecode y buscar todas las instrucciones de bifurcación y secuencias de instrucciones de bucle.
El lenguaje Move admite dos tipos de referencias: referencia inmutable & y referencia mutable &mut. Las referencias inmutables se utilizan para leer datos, mientras que las referencias mutables se utilizan para modificar datos. Usar correctamente los tipos de referencia ayuda a mantener la seguridad y a identificar los módulos de lectura.
El módulo de seguridad de referencias escaneará las instrucciones de bytes de los bloques básicos de la función por unidad de función, verificando que todas las operaciones de referencia sean legales. El proceso de verificación implica principalmente la estructura AbstractState, que incluye el gráfico de préstamos y las variables locales, para garantizar la seguridad de las referencias dentro de la función.
Durante el proceso de verificación, se comparará el estado antes y después de la ejecución del bloque básico, y se fusionarán el estado anterior y el estado posterior según si ha cambiado el join_result. Si hay un cambio y el bloque actual tiene un borde hacia atrás que apunta a sí mismo (lo que indica un bucle), se volverá al inicio del bucle y se continuará ejecutando el bloque básico hasta que el estado posterior sea igual al estado anterior o se interrumpa debido a un error.
Se produce una vulnerabilidad en el proceso de determinar si el resultado de join ha cambiado. Cuando la suma de la longitud de los parámetros y la longitud de la variable local es mayor que 256, el uso de la iteración de tipo u8 sobre locals puede provocar un desbordamiento de enteros. Aunque Move tiene un proceso para comprobar el número de locals, el módulo de verificación de límites solo revisa los locals y no incluye la longitud de los parámetros.
Esta vulnerabilidad de desbordamiento de enteros puede provocar ataques de denegación de servicio (DoS). Un atacante puede construir un bloque de código en bucle y aprovechar el desbordamiento para cambiar el estado del bloque, haciendo que el nuevo mapa de locales sea diferente al anterior. Al volver a ejecutar la función execute_block, el análisis de la secuencia de instrucciones de bytecode en el bloque básico accederá al nuevo mapa de locales. Si el índice que necesita ser accedido por las instrucciones no existe en el nuevo mapa de locales de AbstractState, provocará un DoS.
Para verificar esta vulnerabilidad, se puede reproducir el PoC en git. El bloque de código en el PoC contiene una instrucción de salto incondicional que, al ejecutar la última instrucción, salta de nuevo a la primera instrucción, lo que provoca múltiples llamadas a las funciones execute_block y join.
Esta vulnerabilidad indica que incluso lenguajes enfocados en la seguridad como Move pueden tener riesgos de seguridad. Resalta la importancia de la auditoría de código y sugiere a los diseñadores del lenguaje Move que incorporen más comprobaciones de código en tiempo de ejecución para prevenir situaciones inesperadas. Actualmente, Move realiza comprobaciones de seguridad principalmente en la fase de verificación, pero una vez que se elude la verificación, la falta de un reforzamiento de seguridad adecuado en la fase de ejecución puede resultar en 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 hallazgos en el futuro.