Importante error de Ethereum (ETH) podría estar finalmente solucionado - U.Today

Implementación de Solución para Ataque de Envenenamiento de Caché

Uno de los clientes de consenso de Ethereum ha implementado una solución para un ataque de envenenamiento de caché de claves públicas de validadores, según una solicitud de extracción en GitHub. Este parche aborda una vulnerabilidad relacionada con el fork Gloas, que podría hacer que algunos nodos rechacen firmas válidas debido a un error en la caché global de claves públicas. Gloas es parte de la capa de consenso de la próxima actualización Glamsterdam.

Descripción del Problema

El problema radica en un mecanismo donde el cliente almacena las claves públicas de los validadores y sus índices en una caché global. Técnicamente, los depósitos que ya están finalizados deberían proporcionar los mismos validadores en cada cadena, aunque la situación es diferente en el límite del fork. Para llevar a cabo el ataque, el atacante necesita tres depósitos pendientes justo antes del fork. El primero es un gran aumento para un validador existente, mientras que los otros dos son nuevas claves: A, con credenciales de constructor, y B, con credenciales de validador regular.

Mecanismo del Ataque

En la cadena canónica, el aumento consume la rotación de saldo, por lo que A y B se procesan después del fork. A se convierte en un constructor, y B toma el siguiente índice de validador. En la cadena lateral del atacante, el validador aumentado es penalizado antes del fork, y su depósito se omite. Esto provoca que A se procese antes, esencialmente tomando el índice de B. La caché defectuosa asumió que ambas cadenas producirían los mismos validadores e importó la clave de A globalmente. Como resultado, en el fork, los nodos afectados rechazarían todas las firmas válidas de B en la cadena canónica y se bifurcarían.

Complejidad del Ataque y Solución Propuesta

Realísticamente, el ataque es complicado, ya que requiere una penalización en el momento adecuado y una cadena lateral, lo que hace que sea poco probable que ocurra por accidente. Según la solicitud de extracción, la solución consiste en agregar claves a la caché global de claves públicas solo una vez que su época de elegibilidad para activación haya finalizado. Además, se ha introducido una nueva estructura llamada HeadPubkeys, que combina claves del estado principal y de la caché global, para que los nodos no pierdan claves si la cadena finaliza sin nuevos bloques.

Aún está por confirmarse si otros clientes de consenso han experimentado un problema similar. En otras palabras, cuanto más se acerque Glamsterdam, más casos límite alrededor del límite del fork los desarrolladores tendrán que detectar.