Les versions de Lightning Development Kit antérieures à v0.2.7 et v0.1.13 exposaient certaines applications Bitcoin Lightning à une attaque par reconnexion susceptible de transformer un paiement transféré en perte. Un pair malveillant du canal pouvait accuser réception d'une mise à jour, se reconnecter, puis prétendre à tort ne l'avoir jamais reçue. Avant le correctif, LDK pouvait signer une transaction d'engagement contradictoire sans l'enregistrer dans le moniteur du canal.
Pourquoi c'est important
L'attaque visait le processus de gestion de l'état des canaux Lightning. Après cette fausse affirmation lors de la reconnexion, le pair malveillant pouvait faire confirmer la transaction contradictoire sur la blockchain Bitcoin et permettre au paiement d'être réglé avec le destinataire suivant. Il pouvait ensuite récupérer le contrat de paiement entrant à son expiration, laissant l'application de transfert supporter la perte alors même qu'elle connaissait normalement le secret de paiement utilisé pour réclamer les fonds.
Le comportement corrigé n'autorise la retransmission que tant que l'accusé de réception du pair reste attendu. Si un pair affirme qu'une mise à jour déjà reconnue n'a pas été reçue, LDK ferme désormais le canal de force à la place.
Les développeurs de LDK ont également corrigé une autre voie de vol dans v0.2.7, liée aux paiements instantanés LSPS2. Un paiement intercepté pouvait indiquer un montant erroné, poussant un service de liquidité à ouvrir un canal et à transférer davantage de Bitcoin que ce que le paiement entrant finançait. Les développeurs doivent aussi tenir compte des contrats de paiement en attente créés par d'anciennes versions, car leurs montants pourraient ne pas avoir été validés.
Impact sur le marché
L'exposition immédiate est d'ordre opérationnel, et non le résultat d'une défaillance du protocole Bitcoin. LDK est compilé dans les applications qui l'utilisent. Les développeurs de portefeuilles et de solutions de paiement doivent donc intégrer le code corrigé de la bibliothèque concernée dans leurs logiciels déployés. La version v0.2.7 corrige le problème de reconnexion sur la branche 0.2 ainsi que la vérification des montants LSPS2, tandis que v0.1.13 intègre le correctif partagé contre la reconnexion pour la branche 0.1.
Les équipes qui exploitent une infrastructure Lightning devraient vérifier les versions de LDK déployées, les canaux ouverts et les contrats LSPS2 en attente. Core Lightning est une implémentation distincte et n'est pas la bibliothèque concernée par ce rapport.
Questions fréquemment posées
-
Quelle vulnérabilité de Lightning les versions corrigées de LDK ont-elles résolue ?
Un pair malveillant du canal pouvait se reconnecter et prétendre à tort n'avoir pas reçu une mise à jour reconnue. Avant le correctif, LDK pouvait signer une transaction d'engagement contradictoire qui n'était pas enregistrée par le moniteur du canal.
-
Quelles versions de LDK corrigent la vulnérabilité de reconnexion ?
LDK v0.2.7 corrige le problème sur la branche 0.2, tandis que v0.1.13 intègre le correctif partagé contre la reconnexion pour la branche 0.1.
-
Comment l'attaque par reconnexion pouvait-elle provoquer une perte de Bitcoin ?
L'attaquant pouvait faire confirmer une transaction contradictoire sur Bitcoin, laisser le paiement transféré parvenir au destinataire suivant, puis récupérer le contrat de paiement entrant à son expiration.
-
Quel autre problème LDK v0.2.7 corrige-t-il ?
La version 0.2.7 corrige aussi un problème de paiement instantané LSPS2 dans lequel un montant de paiement falsifié pouvait conduire un service de liquidité à transférer davantage de Bitcoin qu'il n'en avait reçu.
-
Que doivent faire les développeurs d'applications Lightning ?
Les développeurs doivent intégrer le code LDK corrigé concerné aux applications déployées et vérifier les contrats de paiement LSPS2 en attente créés par d'anciennes versions, car leurs montants pourraient ne pas avoir été validés.
CoinDesk
CZ Binance
TheBlock
Crypto News