Vulnerabilidad en Ethereum afectaría contratos inteligentes tras Constantinople

Un desarrollador de Ethereum ha detectado una posible vulnerabilidad que podría afectar los contratos inteligentes que se desarrollen luego de la actualización Constantinople, cuya activación ha sido reprogramada para el 28 de febrero. Miembros de la Fundación Ethereum desestimaron que tal vulnerabilidad fuera relevante.

La posible vulnerabilidad fue identificada en el protocolo CREATE2 por el desarrollador Jason Carver y discutida originalmente en el canal de AllCoreDevs de Gitter. Posteriormente, un usuario la llevó a debate en el foro de Ethereum Magicians el 8 de febrero.

Según el descubrimiento de Carver, podría suceder que un contrato inteligente ya ejecutado sea reemplazado por otro contrato en la misma dirección con una funcionalidad distinta, lo que podría provocar un robo de fondos.

CREATE2 incluye un hash de código de inicio para generar direcciones que podrían producir intencionalmente un código de contrato arbitrario. Según el foro, existen casos de uso en los que este comportamiento es útil. No obstante, podría suceder que se manipule un contrato que utilice un código de inicio no determinista para que los usuarios no se percaten de que interactúan con un contrato totalmente nuevo en la misma dirección.

Carver menciona cómo ciertos contratos inteligentes que eran inofensivos antes de la actualización, podrían verse afectados luego de que Contantinople entre en funcionamiento. El desarrollador describió un contrato de autodestrucción modificado para ilustrarlo:

Creo que la implicación allí es que cualquier contrato malicioso post-Constantinople se ve turbio desde antes. Pero puede construir un contrato bastante inocuo antes de la actualización, uno que tiene dos resultados posibles de una transacción: {«existe contrato»: «tokens de intercambio», «autodestrucción de contrato»: «perder algo de gas»}. Después de Constantinople, las opciones ahora podrían convertirse en {“existe contrato”: “intercambiar tokens”, “autodestrucción del contrato”: “perder algo de gas”, “reemplazar contrato”: “todas las fichas ERC20 que fueron preaprobadas para el contrato son robadas ”}.

Jason Carver

El desarrollador que detectó la posible falla aseguró que es necesario educar a auditores y programadores en la brevedad posible para mitigar los posibles efectos de CREATE2. Sin embargo, considera «sorprendente» que haya pasado desapercibida hasta el momento.

Por su parte, el jefe de seguridad de la Fundación Ethereum, Martin Holst Swende, también participó en esta discusión y aseguró que la mayoría de los usuarios de AllCoreDevs «son plenamente consientes de los efectos de CREATE2«. De igual manera, aseveró que la mayoría de los desarrolladores y auditores de Ethereum «lamentablemente» no están al tanto de ello.

Ninguno de los desarrolladores habló de una tercera postergación de Constantinople, la cual, luego de su primera postergación, debía ejecutarse entre el 15 y 16 de enero. No obstante, en los mercados predictivos de Augur, algunos usuarios apuestan a que la actualización tampoco llegará el 28 de febrero. El desarrollador Hudson Jameson reiteró por la red social Twitter que no había ningún motivo para postergar la actualización.

Carver indicó, además, que el problema con CREATE2 no se trata, necesariamente, de una falla en la Máquina Virtual de Ethereum (EVM por sus siglas en inglés), sino de un posible «ataque social» que haría la tarea de los auditores mucho más difícil.

Al respecto, Martin Holst Swende señaló que la vulnerabilidad deriva precisamente de los contratos con una función de autodestrucción, los cuales son peligrosos aún antes de que Constantinople entre en funcionamiento. Pese a esto, el usuario que llevó la publicación al foro expresó que esta característica de CREATE2 afectaría directamente la confianza en los contratos inteligentes:

…En algún nivel, esto reduce aún más la confianza que los usuarios finales esperan de que los contratos sean «inmutables». No solo pueden actualizarse, sino que ahora también se pueden volver a implementar. Existe un riesgo de percepción aquí y no podemos culpar a los usuarios (o a los auditores).

rajeevgopalakrishna

Para el jefe de seguridad de la Fundación Ethereum, esta no es una preocupación, ya que solo haría falta auditar un contrato y su historia antes de registrarlo, para comprobar que se comporta de la manera prevista cuando se ejecuta. Además, con el fin de proteger los fondos, determinó que no se debe permitir bajo ninguna circunstancia que se ejecute un contrato con la función de autodestrucción.

De esta manera, no sería necesaria una modificación del código sino una campaña de educación para auditores y programadores que «necesitan» estar al día con los cambios que la actualización Contantinople introduce en el protocolo CREATE y los contratos inteligentes.

Pese a las recomendaciones de Martin Holst Swende, el debate continúa abierto. Algunos usuarios consideran que existen otras implicaciones derivadas de CREATE2 que todavía no han sido descubiertas.

Imagen destacada por zoommachine / stock.adobe.com