Por Canuto  

Una falla en versiones sin parche de LDK podía permitir que un par de canal negara, tras reconectarse, haber recibido una actualización y provocara pérdidas en pagos reenviados. La versión 0.2.7 también corrige un problema distinto relacionado con pagos LSPS2.
***

  • LDK publicó las versiones 0.2.7 y 0.1.13 para corregir la vulnerabilidad de reconexión en sus ramas respectivas.
  • La falla podía llevar a firmar una transacción de compromiso conflictiva y dejar al nodo de reenvío sin recuperar los fondos entrantes.
  • La versión 0.2.7 suma una corrección para pagos LSPS2; la 0.1.13 enumera el parche de reconexión, pero no ese arreglo adicional.

LDK corrige una falla que podía dejar pagos de Bitcoin sin recuperar

La vulnerabilidad afectaba aplicaciones construidas con versiones sin parche de Lightning Development Kit (LDK), una biblioteca para crear billeteras de Bitcoin Lightning y servicios de pago. Un par de canal malicioso podía aprovechar una reconexión para negar que había recibido una actualización y desencadenar un escenario de pérdida para el nodo que reenviaba un pago.

LDK publicó el 1 de octubre las versiones 0.2.7 y 0.1.13, que corrigen el problema en las ramas 0.2 y 0.1, respectivamente. Los desarrolladores deben incorporar el código actualizado en las aplicaciones que mantienen, ya que el SDK se compila y ejecuta dentro de esos productos.

Cómo funcionaba el engaño tras la reconexión

El ataque descrito comenzaba cuando un par de canal reconocía una actualización y, después de reconectarse, afirmaba que nunca la había recibido. Antes del parche, LDK podía aceptar esa declaración y firmar una transacción de compromiso incompatible con el estado que el canal ya había acordado.

Una transacción de compromiso representa el estado de un canal y puede servir para liquidarlo en la blockchain de Bitcoin. El problema no consistía simplemente en una interrupción de conexión: la discrepancia entre el reconocimiento previo y la versión que el par decía recordar podía llevar a que el software firmara una transacción conflictiva.

El escenario técnico aparece en la propuesta de cambio PR 5057. Según la descripción del fallo, la transacción recién firmada no quedaba registrada por el monitor de canal de LDK, el componente encargado de seguir las reclamaciones que pueden realizarse en cadena para ese canal.

Esa brecha podía dejar al nodo de reenvío expuesto en dos etapas relacionadas. El par malicioso podía confirmar la transacción en la blockchain y permitir que el pago se liquidara con el siguiente destinatario; luego, cuando venciera el contrato del pago entrante, podía reclamar esos fondos aunque el nodo de reenvío conociera el secreto que normalmente le habría permitido hacerlo.

El riesgo para los pagos reenviados

En Lightning, un nodo puede recibir un pago por un canal y reenviarlo por otro, de modo que el flujo depende de que ambas partes cumplan las condiciones correspondientes. En el caso descrito, el operador malicioso podía aprovechar la diferencia entre el pago que salió hacia el siguiente destinatario y el que debía llegar desde el tramo anterior.

El resultado posible era que la aplicación de reenvío pagara al siguiente destinatario, pero no recuperara los fondos entrantes que debían respaldar esa operación. No se trataba de una pérdida automática para cualquier usuario de Lightning, sino de un riesgo ligado a una secuencia concreta: reconocimiento de una actualización, reconexión, negación de ese reconocimiento y uso de una transacción de compromiso conflictiva.

La corrección modifica el manejo de los mensajes de actualización y de los reconocimientos del par. LDK permite retransmitir una actualización solo mientras el reconocimiento correspondiente siga pendiente; si el par asegura que omitió una actualización que ya había reconocido, el software fuerza el cierre del canal.

Ese cierre busca evitar que la discrepancia continúe y termine convertida en una disputa sobre qué estado del canal puede presentarse en cadena. La descripción técnica de Bitcoin Optech, en su boletín del 9 de octubre, resumió los cambios de seguridad. La protección práctica, sin embargo, depende de que los equipos que mantienen aplicaciones integren la versión corregida.

Qué deben revisar los desarrolladores

Las versiones 0.2.7 y 0.1.13 incorporan la corrección de reconexión en sus respectivas ramas de LDK. Como la biblioteca se compila y ejecuta dentro de cada aplicación, publicar el parche en el SDK no actualiza por sí solo todo el software que ya está desplegado.

Los desarrolladores deben incorporar el código corregido en sus implementaciones y comprobar qué rama utiliza cada producto. La recomendación no implica que toda aplicación Lightning haya sufrido un robo, pero sí identifica una vulnerabilidad que podía afectar a integraciones sin parche cuando un par de canal malicioso ejecutara el engaño descrito.

El alcance también varía según la versión. Las notas de la 0.1.13 enumeran la corrección compartida de reconexión, mientras que la 0.2.7 incluye además un arreglo para un problema distinto asociado con pagos de servicio LSPS2.

Para integraciones LSPS2, la explicación del cambio advierte que contratos de pago que quedaron en cola desde una versión anterior conservan montos no validados. Por eso, los equipos que actualicen la biblioteca también deben tener en cuenta esos contratos pendientes, en lugar de asumir que el cambio de código corrige retroactivamente todos los datos ya almacenados.

Otra corrección incluida en la versión 0.2.7

LSPS2 permite que un servicio de liquidez abra un canal como parte del procesamiento de un pago. En el fallo corregido por la propuesta PR 5042, un pago interceptado podía presentar un monto falso y provocar que el servicio abriera un canal y reenviara más Bitcoin del que proporcionaba el pago entrante.

En ese escenario, el servicio de liquidez habría cubierto la diferencia con sus propios fondos. La verificación del monto incluida en PR 5042 aborda ese riesgo específico del flujo LSPS2, que no debe confundirse con la falla de reconexión descrita en PR 5057.

La diferencia entre ramas importa al evaluar el alcance de cada actualización: la versión 0.2.7 reúne la corrección de reconexión y la de LSPS2, mientras que las notas de la 0.1.13 mencionan el arreglo compartido de reconexión sin listar la corrección de LSPS2. Por ello, los equipos deben consultar las notas de la versión que corresponda a su integración y revisar si ofrecen ese flujo de servicio.

Estos defectos también son distintos de los problemas de desvío de comisiones por operaciones de splice y de carga de estado guardado cubiertos en el informe del 13 de septiembre sobre LDK 0.2.6. La actualización actual aborda la reconexión entre pares y, en el caso de la rama 0.2, la validación de montos en pagos LSPS2; son correcciones diferentes y no deben tratarse como una sola vulnerabilidad.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados