Un fallo en Eclair, una implementación de Bitcoin Lightning, podría permitir a un nodo malicioso bloquear otro sin actualizar, sin financiar un canal ni pagar una comisión en cadena. Afectaba a los nodos con la versión v0.14.0 o anteriores. En una prueba de concepto en regtest, el investigador Erick Cestari agotó una memoria heap de Java de 4 GB en unos 47 minutos y 43 segundos, tras acumularse 217.623 filas en la base de datos de canales. Los registros permanecieron en el disco, por lo que el nodo volvió a quedarse sin memoria durante el arranque.
Por qué importa
Eclair limitaba el número de canales pendientes que podía abrir un nodo, pero la aplicación inconsistente de las comprobaciones de los identificadores temporales y definitivos hacía que el contador registrase menos canales sin financiar de los reales. Un atacante podía acumular solicitudes guardadas y generar costes de memoria y base de datos para el nodo. El ataque seguía requiriendo recursos informáticos y tráfico de red, pero no los BTC que normalmente se comprometen para financiar un canal.
La prueba de concepto muestra una pérdida persistente de disponibilidad en un nodo vulnerable, no ataques en curso ni cuántos operadores se vieron afectados. El tiempo hasta el bloqueo se midió en laboratorio y no es una referencia universal. El fallo se corrigió en v0.14.1, publicada en julio antes de que se divulgara públicamente.
Impacto en el mercado
El hallazgo afecta a la disponibilidad de los nodos Lightning, no demuestra una pérdida de fondos. Una condición de carrera independiente durante la apertura de canales, también corregida en v0.14.1, dejaba procesos huérfanos que consumían recursos; el nodo de prueba se recuperó de ese fallo al desconectarse o reiniciarse. Esa recuperación no se aplica a la saturación persistente de la base de datos.
ACINQ recomienda actualizar a v0.14.3 por otras vulnerabilidades de seguridad. Los operadores cuya base de datos ya esté sobrecargada afrontan una tarea de recuperación aparte: Cestari señaló como posibles medidas aumentar la memoria heap o eliminar manualmente los registros de canales falsos. Reiniciar el nodo repetidamente no borra esos registros.
Preguntas frecuentes
-
¿Por qué puede no restablecer el servicio reiniciar un nodo Eclair afectado?
Los registros de canales sin financiar permanecen en la base de datos. Eclair puede volver a agotar la memoria al cargarlos durante el arranque.
-
¿Exige el ataque de bloqueo persistente financiar un canal de Bitcoin Lightning?
No. Un nodo malicioso podía acumular solicitudes de canales guardadas sin transmitir una transacción de financiación ni pagar una comisión en cadena, aunque el ataque requería recursos informáticos y tráfico de red.
-
¿A qué versiones de Eclair afectaba el fallo y cuál lo corrigió?
El fallo de bloqueo persistente afectaba a los nodos accesibles con v0.14.0 o versiones anteriores. Se corrigió en v0.14.1, publicada en julio antes de la divulgación pública.
-
¿Qué demostró la prueba de concepto de Eclair?
En regtest, agotó una memoria heap de Java de 4 GB tras unos 47 minutos y 43 segundos, con 217.623 filas acumuladas en la base de datos de canales. No demostró ataques reales ni estableció un tiempo de fallo universal.
-
¿Por qué recomienda ACINQ v0.14.3 si v0.14.1 corrigió estos fallos de denegación de servicio?
La versión v0.14.3 aborda otras vulnerabilidades de seguridad. La corrección de los dos fallos de denegación de servicio en v0.14.1 no constituye por sí sola una recomendación de seguridad actual completa.
WuBlockchain
CoinTelegraph
CZ Binance
TheBlock
Crypto News
CoinDesk