Una falla de Core Lightning puede mantener los nodos en caída constante tras una actualización hasta que se elimine un disparador almacenado

Una falla revelada en Core Lightning, el software de la red de pagos Lightning de Bitcoin, puede dejar a un nodo cayendo en cada reinicio incluso después de una actualización, porque el anuncio malicioso que provocó la caída permanece almacenado en disco.

El investigador Nishant Bansal reveló el problema el 24 de octubre, identificando las versiones v25.02 hasta v26.04 como afectadas. Una vez que el anuncio ha sido guardado, cada reinicio vuelve a cargar el mismo disparador, y Bansal señala que el operador debe eliminar manualmente el registro problemático para restaurar el nodo.

Bitcoin Optech, un boletín técnico que sigue los avances de ingeniería de Bitcoin, destacó el problema el 30 de octubre, pero el parche preventivo tiene meses de antigüedad. Core Lightning fusionó el pull request #9082 el 24 de abril y lanzó la corrección en la versión v26.04.1 el 25 de abril. La revelación de octubre, por lo tanto, explica una falla cuya corrección preventiva estaba disponible desde abril.

Por qué el parche no elimina un disparador almacenado

Los anuncios de canal informan a los nodos sobre las conexiones en el grafo de enrutamiento de Lightning. Los pagos saltan a través de estas conexiones registradas, por lo que cada nodo de enrutamiento depende de una copia precisa del grafo para mover fondos. En este caso, un anuncio manipulado nombraba el mismo nodo previamente desconocido como ambos extremos. El software vulnerable lo aceptó, lo escribió en el gossip_store en disco y luego lo cargó en el grafo de enrutamiento.

El grafo intentó entonces insertar ese nodo dos veces. Una salvaguarda contra duplicados abortó gossipd, el componente que maneja estos anuncios, y Core Lightning trató esa falla como fatal para todo el nodo.

El parche verifica el orden de los extremos antes de aceptar un anuncio. Exigir que el primer ID de nodo sea estrictamente menor que el segundo también rechaza los ID iguales, evitando que la entrada malformada sea aceptada y almacenada desde el principio.

Sin embargo, la validación se aplica solo a los anuncios entrantes. El arranque sigue leyendo los registros ya presentes en gossip_store, y la actualización no elimina un registro malicioso guardado antes de la caída. Por eso, el requisito de recuperación de Bansal es la eliminación manual del registro malicioso de gossip_store.

La limpieza por sí sola también deja una instalación vulnerable expuesta a otra caída: según la revelación, un atacante puede reenviar el mismo anuncio mientras el output de financiamiento controlado por el atacante —el output en cadena que abrió el canal— permanezca sin gastar.

Exposición por retransmisión, guía de actualización y riesgo de inactividad

Bitcoin Optech señala que las versiones de Core Lightning anteriores a v25.02 podían aceptar y retransmitir tales anuncios sin caerse por sí mismas. Por lo tanto, un atacante no necesitaba una conexión directa con cada nodo vulnerable, ya que un anuncio retransmitido se reenvía a los pares de cada nodo y puede llevar el registro malformado más adentro de la red.

Para los operadores que elijan actualizar ahora, la v26.04.1 marca la primera versión que contiene la corrección de este defecto. Al 2 de noviembre, la versión más reciente del proyecto es la v26.06.9, publicada el 7 de octubre, que los mantenedores recomiendan fuertemente instalar.

La inactividad conlleva un riesgo de monitoreo de pagos más allá del servicio no disponible. En Lightning, hacer cumplir las reglas de los canales recae en el operador del nodo. Bansal advierte que un nodo fuera de línea no puede vigilar la cadena en busca de un estado de canal revocado ni de un reclamo de pago con plazo limitado que debe realizarse antes de su vencimiento. Perder esos eventos puede poner los fondos en riesgo.

Reportaje original: CryptoSlate