Solana arregla en silencio un error que podría haber permitido que los atacantes se mustifiquen y roben ciertas tokens
La Fundación Solana ha revelado una vulnerabilidad previamente desconocida en su sistema de token centrado en la privacidad que podría haber permitido a los atacantes forjar pruebas falsas de conocimiento cero, lo que permite que los acuñaciones no autorizadas o los retiros de tokens.
se informó por primera vez el 16 de abril a través del asesoramiento de seguridad de ANZA, acompañado de una prueba de trabajo de trabajo. Los ingenieros de los equipos de desarrollo de Solana, Anza, Firedancer y Jito, verificaron el error y comenzaron a trabajar en una solución inmediatamente, según una post-mortem publicada el sábado,
El problema surgió del programa de prueba de elgamal ZK, que verifica las pruebas de conocimiento cero (ZKP) utilizados en las transferencias de Token-22 Confidenciales de Solana. Estos tokens de extensión permiten saldos y transferencias privadas mediante la cifuración de cantidades y el uso de pruebas criptográficas para validarlos.
ZKPS son un método criptográfico que permite a alguien probar que sabe o tiene acceso a algo, como una contraseña o edad, sin revelar la cosa en sí.
En aplicaciones criptográficas, estos pueden usarse para probar que una transacción es válida sin mostrar cantidades o direcciones específicas (que de otro modo pueden ser utilizados por actores maliciosos para planificar las exploits).
El error ocurrió porque algunos componentes algebraicos faltaban del proceso de hash durante la transformación de Fiat-Shamir, un método estándar para hacer pruebas de conocimiento cero no interactivos. (No interactivo significa convertir un proceso de ida y vuelta en una prueba única que cualquiera puede verificar.)
Un atacante sofisticado podría forjar pruebas inválidas de que el verificador de cadena en cadena aún aceptaría. Los tokens SPL o la lógica del programa Token-2022 principal.
Los parches se distribuyeron en privado a los operadores de validador a partir del 17 de abril. Un segundo parche fue presionado más tarde esa noche para abordar un tema relacionado en otra parte de la base de código.
fueron revisados por la empresa de seguridad de terceros, la investigación asymétrica, NEOYME y OTTERSEC. Para el 18 de abril, una supermayoría de validadores había adoptado la solución.
no hay indicios de que el error haya sido explotado, y todos los fondos permanecen seguros, según la post-mortem.
