Vulnerabilidades en Etherium Smart Contracts. Ejemplos de código

Con esta publicación, comienzo una serie de artículos sobre la seguridad de los contratos inteligentes de Ethereum. Creo que este tema es muy relevante, ya que el número de desarrolladores está creciendo como una avalancha, y no hay nadie a quien salvar del "rastrillo". Adiós - traducciones ...

1. Escaneo de contratos de Ethereum en vivo para detectar errores de envío sin marcar

Original: escaneo de contratos de Ethereum en vivo para "Enviar sin marcar ..."

Autores: Zikai Alex Wen y Andrew Miller

Se sabe que la programación de contratos inteligentes de Ethereum es propensa a errores [1] . Recientemente, vimos que varios
Los contratos inteligentes de alta gama como King of the Ether y The DAO-1.0 contenían vulnerabilidades causadas por errores de programación.

Desde marzo de 2015, los programadores de contratos inteligentes han sido advertidos de los peligros de programación específicos que pueden surgir cuando los contratos se envían mensajes entre sí [6] .

Varias guías de programación recomiendan cómo evitar errores comunes (en documentos técnicos Ethereum [3] y en una guía independiente de UMD [2] ). Aunque estos peligros son lo suficientemente comprensibles para evitarlos, las consecuencias de tal error son terribles: el dinero puede ser bloqueado, perdido o robado.

¿Qué tan comunes son los errores resultantes de estos peligros? ¿Hay algún contrato de blockchain de Ethereum más vulnerable pero vivo? En este artículo, respondemos esta pregunta analizando los contratos en la cadena de bloques en vivo de Ethereum utilizando la nueva herramienta de análisis que desarrollamos.

¿Cuál es el error de envío sin marcar?

Para enviar un contrato de tiempo aire a otra dirección, la forma más fácil es usar la palabra clave enviar . Esto actúa como un método definido para cada objeto. Por ejemplo, el siguiente fragmento de código se puede encontrar en un contrato inteligente que implementa un juego de mesa.

/*** Listing 1 ***/ if (gameHasEnded && !( prizePaidOut ) ) { winner.send(1000); //    prizePaidOut = True; } 

El problema aquí es que el método de envío puede fallar. Si no funciona, el ganador no recibirá el dinero, sin embargo, el premio variablePaidOut se establecerá en True.

Hay dos casos diferentes en los que la función winner.send () puede fallar. Analizaremos la diferencia entre ellos más adelante. El primer caso es que la dirección del ganador es un contrato (no una cuenta de usuario), y el código para este contrato arroja una excepción (por ejemplo, si usa demasiado "gas"). Si es así, entonces quizás en este caso sea un "error del ganador". El segundo caso es menos obvio. La máquina virtual Ethereum tiene un recurso limitado llamado " callstack " (profundidad de la pila de llamadas), y este recurso puede ser utilizado por otro código de contrato que se ejecutó previamente en una transacción. Si la pila de llamadas ya se ha agotado cuando se ejecuta el comando de envío , el comando fallará, independientemente de cómo se determine el ganador . ¡El premio del ganador será destruido sin culpa suya!

¿Cómo se puede evitar este error?

La documentación de Ethereum contiene una breve advertencia sobre este peligro potencial [3] : "Existe algún peligro cuando se utiliza el envío: la transmisión falla si la profundidad de la pila de llamadas es 1024 (esto siempre puede ser causado por la persona que llama), y también falla si el destinatario "gas" termina. Por lo tanto, para garantizar una transmisión segura, siempre verifique el valor de retorno del envío, o incluso mejor: use una plantilla en la que el destinatario retire dinero ".

Dos oraciones El primero es verificar el valor de retorno de enviar para ver si se completó con éxito. Si este no es el caso, lanza una excepción para revertir el estado.

  /*** Listing 2 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000)) prizePaidOut = True; else throw; } 

Esta es una solución adecuada para el ejemplo actual, pero no siempre es la decisión correcta. Supongamos que modificamos nuestro ejemplo para que cuando el juego termine, el ganador y el perdedor retrocedan sus fortunas. Una aplicación obvia de una solución "formal" sería la siguiente:

 /*** Listing 3 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000) && loser.send(10)) prizePaidOut = True; else throw; } 

Sin embargo, esto es un error porque introduce una vulnerabilidad adicional. Si bien este código protege al ganador de un ataque de pila de llamadas , también hace que el ganador y el perdedor sean vulnerables entre sí. En este caso, queremos evitar un ataque de pila de llamadas , pero continuar la ejecución si el comando de envío falla por alguna razón.

Por lo tanto, incluso la mejor práctica recomendada (recomendada en nuestra Guía del programador de Ethereum y Serpent, aunque se aplica igualmente a Solidity), es verificar si hay un recurso de pila de llamadas . Podemos definir una macro callStackIsEmpty () , que devolverá un error si y solo si callstack está vacío.

 /*** Listing 4 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (callStackIsEmpty()) throw; winner.send(1000) loser.send(10) prizePaidOut = True; } 

Aún mejor, la recomendación de la documentación de Ethereum: "Usar una plantilla en la que el destinatario toma el dinero" es un poco críptica, pero tiene una explicación. La sugerencia es reorganizar su código para que el efecto del error de envío esté aislado y afecte a un solo destinatario a la vez. El siguiente es un ejemplo de este enfoque. Sin embargo, este consejo también es un antipatrón. Él acepta la responsabilidad de verificar la pila de llamadas a los propios destinatarios, lo que hace posible caer en la misma trampa.

 /*** Listing 5 ***/ if (gameHasEnded && !( prizePaidOut ) ) { accounts[winner] += 1000 accounts[loser] += 10 prizePaidOut = True; } ... function withdraw(amount) { if (accounts[msg.sender] >= amount) { msg.sender.send(amount); accounts[msg.sender] -= amount; } } 

Muchos contratos inteligentes altamente desarrollados son vulnerables. La lotería del Rey del Aire del Trono es el caso más famoso de este error [4] . Este error no se notó hasta que la cantidad de 200 éteres (con un valor de más de 2000 dólares estadounidenses al precio actual) no pudo obtener el ganador legítimo de la lotería. El código correspondiente en King of the Ether es similar al código del Listado 2. Afortunadamente, en este caso, el desarrollador del contrato pudo usar la función no relacionada en el contrato como una "anulación manual" para liberar los fondos atascados. ¡Un administrador menos escrupuloso podría usar la misma función para robar la transmisión!

Continúa escaneando contratos de Ethereum en vivo para detectar errores de envío sin marcar. Parte 2