Estos días he revisado el análisis de seguridad de AEGIS de @Dusk . Al principio solo me quedó grabado: “39 correcciones, 7 críticas”. Después de leer los detalles, me di cuenta de que los números, cuanto más altos, no son lo importante. Los 7 problemas graves finalmente convergieron en 4 categorías de causa raíz: problemas de alias en el sandbox de la VM, deserialización insegura del lado del host, que los cargos y reembolsos de Phoenix no están completamente vinculados, y también una ruta de falsificación de firmas BLS.
¿Por qué hay que mirar las causas raíz, y no solo la cantidad de vulnerabilidades? Porque si el mismo límite de confianza no se dibuja bien, los problemas pueden “reaparecer” una y otra vez en módulos distintos. Por ejemplo: si la entrada no se valida y luego se deserializa, a simple vista parece un error de análisis; en realidad, podría acabar chocando con la seguridad de la memoria del host. El bloque de problemas de Phoenix tampoco es “solo un error pequeño en el cálculo de la comisión”: es que la demostración, las firmas y la ejecución de los reembolsos no comparten la misma semántica; en el peor de los casos, puede afectar la integridad del suministro y la seguridad de los fondos.
Oficialmente se dice que, por el momento, no se han detectado estos críticos aprovechados antes de que se corrigieran. Quiero tomarlo como conclusión de investigación, y no lo convertiré en “no ocurrió absolutamente”. Para $DUSK , la señal positiva de AEGIS es que el equipo hizo público lo que detectó internamente, junto con las causas raíz y la lógica de la reparación. La señal negativa también es clara: tras el lanzamiento en mainnet, el stack central realmente tuvo brechas de alto riesgo que podían afectar la ejecución, la autenticación de consenso y la disponibilidad de la cadena.
Así que no usaré “muchas auditorías” para ponerle a #dusk un sello de seguridad directamente. Lo más útil es observar esto: ¿en la siguiente ronda se seguirá divulgando?, ¿hay pruebas de regresión para los límites del mismo tipo?, ¿la auditoría externa puede cubrir el código después de AEGIS? ¿A ustedes les importa más que nunca se hayan filtrado problemas grandes, o que, después de que se filtren, se puedan explicar bien las causas raíz, el impacto y la cadena de la reparación?
$USELESS $BOME
¿Por qué hay que mirar las causas raíz, y no solo la cantidad de vulnerabilidades? Porque si el mismo límite de confianza no se dibuja bien, los problemas pueden “reaparecer” una y otra vez en módulos distintos. Por ejemplo: si la entrada no se valida y luego se deserializa, a simple vista parece un error de análisis; en realidad, podría acabar chocando con la seguridad de la memoria del host. El bloque de problemas de Phoenix tampoco es “solo un error pequeño en el cálculo de la comisión”: es que la demostración, las firmas y la ejecución de los reembolsos no comparten la misma semántica; en el peor de los casos, puede afectar la integridad del suministro y la seguridad de los fondos.
Oficialmente se dice que, por el momento, no se han detectado estos críticos aprovechados antes de que se corrigieran. Quiero tomarlo como conclusión de investigación, y no lo convertiré en “no ocurrió absolutamente”. Para $DUSK , la señal positiva de AEGIS es que el equipo hizo público lo que detectó internamente, junto con las causas raíz y la lógica de la reparación. La señal negativa también es clara: tras el lanzamiento en mainnet, el stack central realmente tuvo brechas de alto riesgo que podían afectar la ejecución, la autenticación de consenso y la disponibilidad de la cadena.
Así que no usaré “muchas auditorías” para ponerle a #dusk un sello de seguridad directamente. Lo más útil es observar esto: ¿en la siguiente ronda se seguirá divulgando?, ¿hay pruebas de regresión para los límites del mismo tipo?, ¿la auditoría externa puede cubrir el código después de AEGIS? ¿A ustedes les importa más que nunca se hayan filtrado problemas grandes, o que, después de que se filtren, se puedan explicar bien las causas raíz, el impacto y la cadena de la reparación?
$USELESS $BOME
