Este ataque expone un clásico problema de desbordamiento de enteros, que se manifiesta específicamente como un truncamiento de datos durante el proceso de conversión de tipos.
Desglose de detalles técnicos:
1) 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 bits altos.
2) Proceso de ataque:
1. El atacante pasa un parámetro de cantidad de liquidez extremadamente grande a la función add_liquidity; 2. El sistema llama a la función get_delta_b para calcular la cantidad necesaria de tokens B; 3. Durante el proceso de cálculo, al multiplicar dos datos de tipo u128, el resultado teórico debe ser de tipo u256;
Defecto clave: al devolver la función, se convierte forzosamente el resultado u256 a u64, lo que provoca que se trunquen los datos de 128 bits más altos.
3) Efecto de uso: La cantidad de tokens que antes se necesitaba para acuñar un volumen de liquidez ahora se puede completar con una cantidad muy pequeña de tokens. Los atacantes obtienen una gran porción de liquidez a un costo muy bajo y luego realizan arbitraje en el fondo de liquidez al destruir parte de la liquidez.
El lenguaje Move tiene ventajas significativas en la gestión de recursos y la seguridad de tipos, lo que puede prevenir de manera efectiva problemas de seguridad subyacentes como el doble gasto y las fugas de recursos. Sin embargo, el error que se ha presentado en el protocolo Cetus es un error de cálculo matemático a nivel de lógica de aplicación, y no un defecto en el diseño del propio lenguaje Move.
Además, este incidente de seguridad no tiene nada que ver con el mecanismo de consenso, el procesamiento de transacciones, la gestión de estado y otras funciones fundamentales de Sui. 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.
En pocas palabras, 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 de bajo nivel, 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 cálculos matemáticos.
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.
Este ataque expone un clásico problema de desbordamiento de enteros, que se manifiesta específicamente como un truncamiento de datos durante el proceso de conversión de tipos.
Desglose de detalles técnicos:
1) 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 bits altos.
2) Proceso de ataque:
1. El atacante pasa un parámetro de cantidad de liquidez extremadamente grande a la función add_liquidity;
2. El sistema llama a la función get_delta_b para calcular la cantidad necesaria de tokens B;
3. Durante el proceso de cálculo, al multiplicar dos datos de tipo u128, el resultado teórico debe ser de tipo u256;
Defecto clave: al devolver la función, se convierte forzosamente el resultado u256 a u64, lo que provoca que se trunquen los datos de 128 bits más altos.
3) Efecto de uso: La cantidad de tokens que antes se necesitaba para acuñar un volumen de liquidez ahora se puede completar con una cantidad muy pequeña de tokens. Los atacantes obtienen una gran porción de liquidez a un costo muy bajo y luego realizan arbitraje en el fondo de liquidez al destruir parte de la liquidez.
简单类比:就像用只能显示8位数的计算器计算10亿×10亿,20位的计算结果只能显示后8位,前12位直接消失。 攻击者正是利用了这种"计算精度缺少"vulnerability。
El lenguaje Move tiene ventajas significativas en la gestión de recursos y la seguridad de tipos, lo que puede prevenir de manera efectiva problemas de seguridad subyacentes como el doble gasto y las fugas de recursos. Sin embargo, el error que se ha presentado en el protocolo Cetus es un error de cálculo matemático a nivel de lógica de aplicación, y no un defecto en el diseño del propio lenguaje Move.
具体而言,Move的类型系统虽然严格,但对于显式类型转换(explicit casting)操作,仍需依赖开发者的正确判断。 当程序主动执行u256到u64的类型转换时,编译器无法判断这是有意设计还是逻辑错误。
Además, este incidente de seguridad no tiene nada que ver con el mecanismo de consenso, el procesamiento de transacciones, la gestión de estado y otras funciones fundamentales de Sui. 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.
En pocas palabras, 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 de bajo nivel, 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 cálculos matemáticos.