Recompensa de errores de la red Witnet: Error de DOS de Harsh Jain de Harsh Jain Blog de la Fundación Witnet Ago, 2020

Para aquellos que no lo saben, Witnet es una red de Oracle sin permisos descentralizada que planea lanzar Mainnet a mediados de octubre de este año. Actualmente están haciendo pruebas de regresión y ejecutando un programa de incentivos Testnet, incluido un programa de recompensas por errores.

He estado ejecutando un nodo Witnet desde el inicio de este Testnet. Además de eso, también comencé a buscar en el código y a verificar cómo se comunicaban los nodos. Para unirse a la red, un nuevo nodo se comunica con sus pares e intercambia mensajes VERSION y VERACK para consolidar la conexión. Si el intercambio de estos mensajes no ocurre dentro de la duración del tiempo de espera del protocolo de enlace, otro hilo finaliza la conexión. Incluso si el mensaje es erróneo, la conexión está activa al menos durante el tiempo de espera del apretón de manos.

Como resultado, si la cantidad de mensajes se puede aumentar de alguna manera al disminuir su tamaño individual, podemos sobrecargar efectivamente el nodo con una gran cantidad de mensajes e incluso consumir los recursos del hilo que termina la conexión.

Witnet utiliza mensajes codificados con PROTOBUF para la comunicación. El formato de los mensajes PROTOBUF es el siguiente: en primer lugar, cuatro bytes indican la longitud del mensaje L, y el siguiente L bytes abarcan el mensaje real. Entonces, el tamaño más pequeño del mensaje es 4 bytes: 0x00000000, siendo 0 la longitud del mensaje real.

Para la transferencia de datos de 1 Mbps desde un nodo malicioso, los pares recibirán alrededor de 32000 mensajes por segundo (cada mensaje contiene 32 bits). Esta es una gran cantidad de mensajes que se procesarán en 1 segundo y, como resultado, se requieren recursos sustanciales de los nodos y no se llama a la función de tiempo de espera del protocolo de enlace.

Por lo tanto, este error se generó porque la conexión no se cerró y los nodos esperarían la duración del tiempo de espera antes de terminarla. Este ataque fue divulgado responsablemente el 31 de julio. El equipo reconoció la posibilidad de DOS y la solucionó en una semana.