Versión simplificada: interpretación simple de la "traducción" del experto sobre @CetusProtocol
Análisis de incidentes de ataques hackers:
Este ataque expone un clásico problema de desbordamiento de enteros, que se manifiesta específicamente como una truncamiento de datos durante el proceso de conversión de tipos.
Desglose de detalles técnicos:
Localización de vulnerabilidades: El problema se presenta en el mecanismo de conversión de tipos de la función get_amount_by_liquidity, donde la conversión forzada de u256 a u64 provoca la pérdida de datos de orden superior.
Proceso de ataque:
El atacante pasa un gran número de parámetros de cantidad de liquidez a través de la función add_liquidity;
El sistema llama a la función get_delta_b para calcular la cantidad necesaria de tokens B;
Durante el proceso de cálculo, la multiplicación de dos datos de tipo u128 debería dar como resultado teórico un tipo u256;
Defecto clave: al devolver la función, se convierte forzosamente el resultado u256 a u64, lo que provoca que se recorten los 128 bits altos de los datos.
Efecto de uso: La cantidad de liquidez que originalmente requería una gran cantidad de tokens, ahora se puede completar con una cantidad mínima de tokens. Los atacantes obtienen una enorme participación en la liquidez a un costo muy bajo y luego realizan arbitraje en el fondo mediante la destrucción de parte de la liquidez.
Analogía simple: es como usar una calculadora que solo puede mostrar 8 dígitos para calcular 1 billón × 1 billón, el resultado de 20 dígitos solo puede mostrar los últimos 8 dígitos, los 12 dígitos anteriores desaparecen directamente. El atacante está aprovechando esta vulnerabilidad de "pérdida de precisión en los cálculos".
Es necesario aclarar un punto: esta vulnerabilidad no está relacionada con la arquitectura de seguridad subyacente de @SuiNetwork, la seguridad del lenguaje Move "brillo" aún es confiable por el momento. ¿Por qué?
El lenguaje Move tiene ventajas significativas en la gestión de recursos y la seguridad de tipos, pudiendo prevenir eficazmente problemas de seguridad subyacentes como el doble gasto y la fuga de recursos. Sin embargo, lo que ha ocurrido en el protocolo Cetus es un error de cálculo matemático a nivel de lógica de aplicación, y no un defecto de diseño del propio lenguaje Move.
En concreto, aunque el sistema de tipos de Move es estricto, para las operaciones de conversión de tipos explícitos (explicit casting), todavía depende del juicio correcto del desarrollador. Cuando el programa realiza activamente la conversión de tipo de u256 a u64, el compilador no puede determinar si esto es un diseño intencionado o un error lógico.
Además, este incidente de seguridad no tiene nada que ver con el mecanismo de consenso, el procesamiento de transacciones, la gestión de estados y otras funciones básicas del Sui. La Sui Network simplemente ejecutó fielmente las instrucciones de transacción enviadas por el protocolo Cetus; la vulnerabilidad proviene de un defecto lógico en el propio protocolo de la capa de aplicación.
Dicho de manera simple, ningún lenguaje de programación, por avanzado que sea, puede eliminar por completo los errores lógicos en la capa de aplicación. Move puede prevenir la mayoría de los riesgos de seguridad a nivel de base, pero no puede reemplazar a los desarrolladores en la verificación de límites de la lógica de negocio y la protección contra desbordamientos en operaciones matemáticas.
Corrección:
He hablado más a fondo con el experto, anteriormente había desviaciones en los detalles específicos del análisis técnico del ataque hacker a @CetusProtocol, por lo que hago esta corrección.
Previamente se identificó con precisión que esta es una vulnerabilidad de desbordamiento en cálculos matemáticos, el atacante al construir un valor especial "aprovecharse de lo pequeño para ganar lo grande" tiene la lógica correcta, y también es correcto en responder las dudas sobre la seguridad del lenguaje Move que preocupan a todos.
Solo se observó el fenómeno de un error de cálculo matemático, suponiendo que era un problema de conversión de tipos, pero en realidad era un problema de verificación de límites de otras funciones. De hecho, el lenguaje Move tiene un mecanismo de revisión estricto para la conversión de tipos, como de u256 a u64; este tipo de conversiones explícitas, en condiciones normales, realmente tendrá una verificación de seguridad.
La ubicación específica de la vulnerabilidad y el mecanismo de implementación técnica necesitan ser corregidos, como se indica a continuación.
El verdadero problema surge en el mecanismo de verificación de desbordamiento de la función get\_delta\_a, que ha fallado:
1）Función: calcular la cantidad de token A necesaria al agregar liquidez específica;
Defecto clave: la comprobación de desbordamiento de la función checked\_shlw presenta un error de codificación, lo que no impide valores de liquidez grandes e inválidos;
Aprovechamiento de ataques: los hackers construyen un valor de liquidez especial, eludiendo la verificación de fallos, y finalmente, a través del mecanismo de redondeo hacia arriba de div\_round, hacen que la cantidad requerida del token A se convierta en 14).
Efecto del ataque: acuñar una enorme liquidez con 1 token A y luego vaciar el fondo.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Interpretación del análisis del experto sobre el ataque hacker al protocolo Cetus
Versión simplificada: interpretación simple de la "traducción" del experto sobre @CetusProtocol
Análisis de incidentes de ataques hackers:
Este ataque expone un clásico problema de desbordamiento de enteros, que se manifiesta específicamente como una truncamiento de datos durante el proceso de conversión de tipos.
Desglose de detalles técnicos:
Localización de vulnerabilidades: El problema se presenta en el mecanismo de conversión de tipos de la función get_amount_by_liquidity, donde la conversión forzada de u256 a u64 provoca la pérdida de datos de orden superior.
Proceso de ataque:
El atacante pasa un gran número de parámetros de cantidad de liquidez a través de la función add_liquidity;
El sistema llama a la función get_delta_b para calcular la cantidad necesaria de tokens B;
Durante el proceso de cálculo, la multiplicación de dos datos de tipo u128 debería dar como resultado teórico un tipo u256;
Defecto clave: al devolver la función, se convierte forzosamente el resultado u256 a u64, lo que provoca que se recorten los 128 bits altos de los datos.
Analogía simple: es como usar una calculadora que solo puede mostrar 8 dígitos para calcular 1 billón × 1 billón, el resultado de 20 dígitos solo puede mostrar los últimos 8 dígitos, los 12 dígitos anteriores desaparecen directamente. El atacante está aprovechando esta vulnerabilidad de "pérdida de precisión en los cálculos".
Es necesario aclarar un punto: esta vulnerabilidad no está relacionada con la arquitectura de seguridad subyacente de @SuiNetwork, la seguridad del lenguaje Move "brillo" aún es confiable por el momento. ¿Por qué?
El lenguaje Move tiene ventajas significativas en la gestión de recursos y la seguridad de tipos, pudiendo prevenir eficazmente problemas de seguridad subyacentes como el doble gasto y la fuga de recursos. Sin embargo, lo que ha ocurrido en el protocolo Cetus es un error de cálculo matemático a nivel de lógica de aplicación, y no un defecto de diseño del propio lenguaje Move.
En concreto, aunque el sistema de tipos de Move es estricto, para las operaciones de conversión de tipos explícitos (explicit casting), todavía depende del juicio correcto del desarrollador. Cuando el programa realiza activamente la conversión de tipo de u256 a u64, el compilador no puede determinar si esto es un diseño intencionado o un error lógico.
Además, este incidente de seguridad no tiene nada que ver con el mecanismo de consenso, el procesamiento de transacciones, la gestión de estados y otras funciones básicas del Sui. La Sui Network simplemente ejecutó fielmente las instrucciones de transacción enviadas por el protocolo Cetus; la vulnerabilidad proviene de un defecto lógico en el propio protocolo de la capa de aplicación.
Dicho de manera simple, ningún lenguaje de programación, por avanzado que sea, puede eliminar por completo los errores lógicos en la capa de aplicación. Move puede prevenir la mayoría de los riesgos de seguridad a nivel de base, pero no puede reemplazar a los desarrolladores en la verificación de límites de la lógica de negocio y la protección contra desbordamientos en operaciones matemáticas.
Corrección:
He hablado más a fondo con el experto, anteriormente había desviaciones en los detalles específicos del análisis técnico del ataque hacker a @CetusProtocol, por lo que hago esta corrección.
Previamente se identificó con precisión que esta es una vulnerabilidad de desbordamiento en cálculos matemáticos, el atacante al construir un valor especial "aprovecharse de lo pequeño para ganar lo grande" tiene la lógica correcta, y también es correcto en responder las dudas sobre la seguridad del lenguaje Move que preocupan a todos.
Solo se observó el fenómeno de un error de cálculo matemático, suponiendo que era un problema de conversión de tipos, pero en realidad era un problema de verificación de límites de otras funciones. De hecho, el lenguaje Move tiene un mecanismo de revisión estricto para la conversión de tipos, como de u256 a u64; este tipo de conversiones explícitas, en condiciones normales, realmente tendrá una verificación de seguridad.
La ubicación específica de la vulnerabilidad y el mecanismo de implementación técnica necesitan ser corregidos, como se indica a continuación.
El verdadero problema surge en el mecanismo de verificación de desbordamiento de la función
get\_delta\_a, que ha fallado:1）Función: calcular la cantidad de token A necesaria al agregar liquidez específica;
Defecto clave: la comprobación de desbordamiento de la función
checked\_shlwpresenta un error de codificación, lo que no impide valores de liquidez grandes e inválidos;Aprovechamiento de ataques: los hackers construyen un valor de liquidez especial, eludiendo la verificación de fallos, y finalmente, a través del mecanismo de redondeo hacia arriba de
div\_round, hacen que la cantidad requerida del token A se convierta en 14).Efecto del ataque: acuñar una enorme liquidez con 1 token A y luego vaciar el fondo.