Como parte de la preparación para la próxima actualización del protocolo Streamflow de Livepeer, el proyecto se sometió a una auditoría externa con la firma de investigación de seguridad Trail of Bits. El objetivo del proceso de auditoría era centrarse en descubrir cualquier problema de seguridad que pudiera haberse introducido desde que se realizó la auditoría inicial antes del lanzamiento a principios de 2018. En el transcurso de tres semanas, ToB revisó la actualización de Streamflow, documentó los posibles problemas que descubrió, observó áreas potenciales para mejoras en la calidad del código y registró sus hallazgos en su informe oficial, que puede ver aquí.
El alcance de la auditoría fue sobre los contratos inteligentes del Protocolo y el nuevo mecanismo de pagos en Streamflow. Hizo las siguientes preguntas:
¿Se puede detener la ronda y la progresión del protocolo, evitando que el protocolo avance? ¿Hay vulnerabilidades en el mecanismo de actualización que permitirían a un usuario malintencionado tomar el control de los contratos? ¿El usuario malintencionado obliga a todos los tickets de pago a ganar (o perder) sin ser detectado por el usuario en el otro extremo de la transacción?
El informe destaca dos problemas de gravedad media, un problema de gravedad baja y dos problemas de gravedad indeterminados. Livepeer abordó cada punto planteado por ToB en la sección de Respuesta del informe de auditoría, y proporcionó un cambio de código recientemente revisado, o indicó cómo los diferentes actores del protocolo defendieron el problema informado.
Junto con las auditorías privadas de las empresas de seguridad, Livepeer busca la revisión pública de la comunidad abierta de participantes e investigadores del protocolo. Como tal, Livepeer ejecuta un programa continuo de recompensas por errores, en el que las recompensas se pagan en relación con la gravedad de los problemas descubiertos, siempre que se divulguen de manera responsable.
Nota: hasta $ 50 USD Bajo: hasta $ 100 USD Medio: hasta $ 250 USD Alto: hasta $ 1000 USD Crítico: hasta $ 2500 USD
Consulte la página wiki de bug bounty para obtener una descripción completa del programa y los procesos de divulgación.
Según el informe de auditoría publicado para Streamflow, las siguientes áreas de enfoque se consideran de alto impacto y estarían sujetas a mayores recompensas:
El protocolo Livepeer progresa en rondas y cada ronda debe inicializarse para que se lleven a cabo otras acciones (es decir, canje de boletos, replanteo, etc.). ¿Puede algo detener la progresión de la ronda y evitar que tenga lugar la inicialización de la ronda? Streamflow es una actualización de protocolo centrada en la escalabilidad y todavía se basa en un mecanismo de actualización centralizado controlado por el equipo central por el momento. Es crucial que el equipo central pueda conservar la propiedad de los contratos en el sistema, ya que los propietarios de estos contratos pueden actualizar los valores de los parámetros económicos, corregir errores e implementar actualizaciones. ¿Existe alguna vulnerabilidad que permita a un actor malintencionado tomar posesión de estos contratos y acceder a las capacidades antes mencionadas? Los usuarios apuestan tokens Livepeer a través de los contratos implementados. Los usuarios también custodian ETH con los contratos implementados que se utilizan para pagar el trabajo en la red. ¿Puede algo poner en riesgo este valor de usuario de manera que pueda quedar encerrado permanentemente en los contratos o ser robado por actores maliciosos?
Además de los objetivos anteriores, hay varias áreas relacionadas con la actualización de Tributario a Streamflow que serían elegibles para recompensas:
¿Es posible la corrupción estatal para cualquiera de los contratos actualizados, por ejemplo, debido a los riesgos de corrupción estatal inherentes al mecanismo de actualización del proxy de delegado de llamada? ¿Existe alguna posibilidad de comportamiento inesperado en la interacción entre los contratos nuevos / actualizados compilados con solc 0.5.xy los contratos antiguos? compilado con solc <0.5.x? ¿Hay algún caso en el que la nueva lógica de actualización de estado en el BondingManager actualizado haga suposiciones inválidas durante la transición de V1 a Streamflow? ¿Es posible que un atacante fuerce todos los tickets de micropagos probabilísticos enviados desde una emisora a ¿siempre gana a pesar de que la probabilidad de que los boletos sean inferiores al 100%? ¿Es posible que un atacante malintencionado obligue a todos los boletos probables de micropagos recibidos por un orquestador a perder siempre a pesar de que la probabilidad de ganar sea mayor que 0?
Si profundiza en el código del protocolo Livepeer y tiene preguntas relacionadas con cualquiera de los anteriores, comuníquese con [email protected]. Gracias.
