Uno de los clientes de consenso de Ethereum ha fusionado una solución para un ataque de envenenamiento de la caché de claves públicas de validadores, según una solicitud de extracción en GitHub. El parche aborda una vulnerabilidad en torno al fork Gloas, que podría provocar que algunos nodos rechacen firmas válidas debido a un error en la caché global de claves públicas.
Gloas es la parte de la capa de consenso de la próxima actualización Glamsterdam.
Tres depósitos, dos cadenas
El problema radica en un mecanismo mediante el cual 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 dar los mismos validadores en cada cadena, aunque es una historia diferente en el límite del fork.
El atacante necesita 3 depósitos pendientes justo antes del fork. El primero es una gran recarga para un validador existente. Los otros dos son claves nuevas: A con credenciales de constructor y B con credenciales de validador normales.
En la cadena canónica, la recarga consume la rotación de saldo, por lo que A y B se procesan después del fork. A se convierte en constructor y B toma el siguiente índice de validador.
En la cadena lateral del atacante, el validador recargado es penalizado antes del fork y su depósito se omite. Esto hace que A se procese antes, esencialmente tomando el índice de B.
La caché defectuosa asumía que ambas cadenas producirían los mismos validadores e importó la clave de A globalmente.
En el fork, los nodos afectados rechazarían todas las firmas válidas de B en la cadena canónica y se bifurcarían.
En la práctica, el ataque es algo complicado, ya que necesita una penalización en el momento adecuado y una cadena lateral, por lo que es poco probable que ocurra por accidente.
¿Qué cambia la solución?
Según la PR, la solución consiste en añadir claves a la caché global de claves públicas solo una vez que su época de elegibilidad de activación esté finalizada.
Una nueva estructura HeadPubkeys también combina claves del estado de cabeza y de la caché global, para que los nodos no pierdan claves si la cadena se finaliza sin nuevos bloques.
Aún está por confirmarse si otros clientes de consenso tenían un problema similar. En otras palabras, cuanto más se acerca Glamsterdam, más casos límite en torno al límite del fork tienen que detectar los desarrolladores.
