Zeitgeist completa todas las auditorías de código
Recientemente hemos completado dos rondas de auditorías de código en nuestro software, y a continuación presentamos un resumen detallado del informe más reciente realizado por el equipo de Chaintroopers.
Recientemente hemos completado dos rondas de auditorías de código en nuestro software, y a continuación presentamos un resumen detallado del informe más reciente realizado por el equipo de Chaintroopers.
Ha habido mucho trabajo detrás de los bastidores aquí en Zeitgeist mientras nos preparamos para que nuestra aplicación entre en funcionamiento. Para tener una experiencia eficiente y de alta calidad en los mercados de predicción, necesitábamos asegurarnos de que no había errores o problemas importantes con nuestro software, y por ello empleamos el uso de algunos auditores de código líderes que nos ayudaran.
A la vez que contratamos a otro grupo de desarrolladores de blockchain de Substrate que tienen una amplia experiencia en proyectos de Polkadot, también utilizamos los servicios de Chaintroopers, que se enorgullece de ser uno de los principales expertos en seguridad de blockchain del ecosistema. Chaintroopers tuvo la amabilidad de hacer público su elaborado informe, por lo que, en vista de ello, y en beneficio de la transparencia, nos gustaría compartir con ustedes algunas de las principales conclusiones que hicieron durante su auditoría (señalando que este informe específico es una de las dos auditorías de código completadas en el software Zeitgeist).
Chaintroopers dividió los problemas que descubrió en cuatro categorías:
1. 1. Alto riesgo
2. 2. Riesgo medio
3. Riesgo bajo
4. Informativo
La empresa descubrió un total de catorce problemas con el código Zeitgeist sobre los que merecía la pena actuar, de los cuales cuatro entraban en la categoría de riesgo alto, tres se clasificaban como de riesgo medio, cuatro se consideraban de “riesgo bajo” y los tres últimos se consideraban “informativos”.
Problemas de alto riesgo
Los problemas de alto riesgo estaban relacionados principalmente con la lógica de negocio y la validación de datos, en los que los problemas de lógica de negocio habrían permitido a los actores maliciosos explotar nuestro protocolo, provocando ataques de denegación de servicio. Los problemas de validación de datos de alto riesgo estaban relacionados con los mercados sin permisos, que habrían permitido a actores maliciosos abusar de las funciones de “autorización de mercado” y rechazar por la fuerza los mercados de su elección, mientras que otro problema de validación de datos descubrió que la llamada de envío disponible públicamente para crear mercados categóricos no estaba marcada como transaccional (esto habría provocado que los fondos del usuario siguieran reservados en caso de error).
Problemas de riesgo medio
Las vulnerabilidades de riesgo medio también estaban relacionadas con la validación de datos y la lógica empresarial, esta vez una de ellas relacionada con la validación de datos y dos con la lógica empresarial. Había un fondo de subvenciones que no tenía una cantidad mínima requerida, lo que habría permitido a los atacantes abusar de los fondos disponibles de la pool. En cuanto a los problemas de lógica de negocio de riesgo medio, se encontró un problema por el que la función “rechazar mercado” ignoraba el estado del mercado (lo que podía provocar que los mercados exitosos se eliminaran innecesariamente de la aplicación). Y el tercer problema de riesgo medio estaba directamente relacionado con este problema de “mercado rechazado”, por el que las cuotas de mercado de resultados relacionadas no eran gestionadas por la funcionalidad de rechazo, lo que significaba que en el caso de un mercado rechazado con activos de resultados asociados, los fondos reservados no se liberaban.
Problemas de bajo riesgo
Tres de los problemas de bajo riesgo estaban relacionados con las funciones de administración, mientras que uno estaba relacionado con las cuotas de mercado de resultados en los mercados categóricos. La primera función de administración permitía que una paleta emitiera eventos cuando quisiera notificar a entidades externas sobre cambios o condiciones en el tiempo de ejecución a entidades externas, pero se recomendaba más bien emitir eventos relacionados con la funcionalidad administrativa específica. La segunda cuestión de bajo riesgo vio los tipos de mercado proporcionados en las funcionalidades “admin_set_pool_as_stale” y en “set_pool_as_stale”, pero esta información podría almacenarse en la entidad de la pool para evitar tomar decisiones de seguridad posteriores sobre los parámetros proporcionados por el usuario.
El tercer problema de bajo riesgo identificó que no se requería una cantidad mínima en la funcionalidad de envío disponible al público para comprar un conjunto completo de acciones de resultados de un mercado, lo que permitía a los usuarios emitir solicitudes por cantidades nulas. El cuarto problema de bajo riesgo detectó que ciertas funciones de administración no utilizan el “deposit_event”, faltando también algunos eventos correspondientes.
Problemas de información
Los problemas informativos están relacionados principalmente con la documentación de Zeitgeist, y pueden dificultar a los desarrolladores la búsqueda y corrección de vulnerabilidades. Chaintroopers encontró los siguientes problemas de documentación/información que necesitaban ser corregidos:
El primer problema informativo identificado fue que una función dispatchable de Substrate asociada a elementos de los bloques de código “impl” no estaba incluida en la documentación de la palett examinada. El segundo fue que no se definieron límites superiores para el valor “range.end” de los Períodos de Mercado, y el tercer problema informativo fue que el “admin_move_market_to_closed” no maneja los casos en los que el “current_block” o el “ T::MarketCommons::now()” es menor que el valor “range.start”.
Conclusión
Todos los catorce problemas mencionados fueron debidamente comunicados con todo detalle al equipo de ingenieros de Zeitgeist, y nos pusimos a trabajar inmediatamente para solucionarlos. En las dos semanas siguientes al informe, pedimos a Chaintroopers que comprobara cada uno de los problemas y se asegurara de que habían sido tratados adecuadamente. Nos complace informar de que Chaintroopers examinó a fondo nuestras correcciones y quedó satisfecho con la forma en que las llevamos a cabo.
Así, el equipo de Chaintroopers cerró la auditoría unas semanas más tarde y elaboró este extenso informe que nos complace poner a disposición de los usuarios aquí.
Estamos agradecidos por el trabajo de Chaintroopers en el examen de nuestro software, y apreciamos su actitud profesional y comunicativa en todo momento. Siempre hemos dicho que nuestra ambición es construir el mejor software de Mercados de Predicción disponible, y estas auditorías de código son imprescindibles para lograrlo. Estamos seguros de que contamos con un protocolo mucho mejor gracias al trabajo de Chaintroopers y de los demás participantes en estas auditorías, y no podemos esperar a lanzar nuestro software mejorado al mundo.
