Incidentes Asociados
Reflexiones sobre el truco de DAO
Acabamos de vivir el escenario de pesadilla que nos preocupaba cuando pedimos una moratoria en The DAO: alguien explotó una debilidad en el código de The DAO para vaciar más de 2 millones ($ 40 millones de dólares) de éter.
El exploit parece haberse centrado en el problema de reentrada en la función 'splitDAO'. El problema de la reentrada está relacionado con el problema del envío no verificado que se discutió ayer en este blog, pero es distinto. Ambos problemas son bien conocidos, identificados por la auditoría de Least Authority de la máquina virtual Ethereum como problemas que pueden afectar a las aplicaciones, así como la reciente publicación de blog de Peter Vessenes. En esencia, una llamada que parece una llamada normal se puede convertir fácilmente en una llamada recursiva y, a menos que la aplicación esté codificada con mucho cuidado, se puede usar para realizar retiros múltiples cuando solo se debe permitir uno. Parece que el atacante aprovechó para retirar sumas sustanciales.
Mis reacciones inmediatas a este truco son las siguientes.
¿Qué es un truco cuando no tienes una especificación? En primer lugar, ni siquiera estoy seguro de que esto califique como un truco. Para etiquetar algo como un truco, un error o un comportamiento no deseado, necesitamos tener una especificación del comportamiento deseado. No teníamos tal especificación para The DAO. No existe una especificación independiente de lo que se supone que debe implementar la DAO. Diablos, casi no hay comentarios en el código DAO que documenten lo que los desarrolladores pueden haber estado pensando en el momento en que escribieron el código. El "código era su propia documentación", como dice la gente. Era su propia letra pequeña. El hacker leyó la letra pequeña mejor que la mayoría, mejor que los propios desarrolladores. Si el atacante hubiera perdido dinero por error, estoy seguro de que los desarrolladores no habrían tenido dificultades para apropiarse de sus fondos y decir "esto es lo que sucede en el nuevo y valiente mundo de los flujos de dinero programáticos". Cuando, en cambio, vació las monedas de The DAO, la única respuesta consistente es llamarlo un trabajo bien hecho.
No hay refugio seguro en este momento Podría pensar que, frente a un atacante en The DAO, podría simplemente tomar sus fondos y estar seguro. Pero este no es el caso aquí. Los desarrolladores de DAO decidieron dificultar la extracción de fondos de The DAO. Por lo tanto, no le dieron a la gente la opción de "simplemente sacar fondos". En cambio, un inversionista de DAO puede crear un nuevo "DAO infantil" y mover sus fondos al niño y mantenerlos allí durante 27 días; no hay retiro directo. El problema es que el DAO secundario es exactamente el mismo código que el principal y tiene exactamente la misma vulnerabilidad. Convertir al niño de nuevo en éter toma otros 34 días; reemplazar el DAO secundario con un contrato actualizado toma un mínimo de 7 días. Entonces, el atacante, si así lo desea, podría acechar a las personas en los DAO de sus hijos y drenarlos antes de que tengan la oportunidad de actualizar sus contratos. No creo que haga esto: si llegara a este nivel de odio, ciertamente invocaría una censura específica.
Mover fondos tiene un costo El DAO no fue diseñado para tener una función de "actualización" fácil. En particular, en este momento, parece que no hay forma de sacar el DAO de su estado actual y restablecerlo en un código de contrato más nuevo, manteniendo intacto su estado interno. La cuenta "extraBalance", en particular, no es transferible a través de actualizaciones de "newContract". Esto significa que la cantidad extraBalance, por valor de unos pocos millones de dólares, es una cancelación.
El experimento DAO ha terminado Prácticamente, esto debería marcar el final de The DAO. La gente de SlockIt debería trabajar duro para desmantelar el fondo y devolver las monedas a los inversores de la manera más ordenada posible.
¿Ethereum/Solidity es adecuado para contratos inteligentes seguros? Está claro que escribir un contrato inteligente sólido y seguro requiere una gran diligencia. Es más similar a escribir código para un reactor de energía nuclear que escribir código web suelto. Sin embargo, el lenguaje Solidity actual y el EVM subyacente parecen diseñados más para este último. Algunas fallas son: Un buen lenguaje para escribir máquinas de estado garantizaría que no haya estados de los que sea imposible recuperarse.
Un buen lenguaje para escribir máquinas de estado dejaría dolorosamente claro cuándo las transiciones de estado pueden y no pueden ocurrir.
Un buen lenguaje para mantener máquinas de estado proporcionaría características para mejorar la seguridad de un contrato en vivo.
Un buen lenguaje para escribir código seguro dejaría en claro que no hay acciones implícitas, que el código se ejecuta claramente, tal como se lee. El lenguaje actual no cumple ninguno de estos mandamientos y, de hecho, el último, que involucra llamadas recursivas implícitas, es lo que involucró a The Dao. El equipo de SlockIt incluso hizo que el diseñador e implementador de Solidity realizara una revisión de su código. Si él no puede hacer que algo como The DAO sea seguro, nadie puede hacerlo. Parece necesario un replanteamiento.
Ataques de imitación La principal preocupación en este momento tiene que ver con los ataques de imitación. Otros pueden aprender de este ataque y lanzar exactamente el mismo.
Detener al atacante La gran incógnita es cómo reaccionará la comunidad ethereum. Por un lado, hacer retroceder el ethereu.