Une transaction d’engagement représente l’état convenu d’un canal et peut être utilisée pour le régler sur la blockchain de Bitcoin. Dans le scénario décrit dans le PR 5057, la transaction nouvellement signée n’a pas été enregistrée par le moniteur de canal de LDK, le composant qui suit les réclamations en chaîne du canal.
Cet écart pourrait transformer un paiement transféré en perte. L’expéditeur malveillant pourrait confirmer la transaction en chaîne et laisser le paiement être réglé avec le prochain destinataire. Il pourrait alors récupérer le contrat de paiement entrant à son expiration, même si le nœud de transfert connaissait le secret normalement utilisé pour réclamer le paiement.
La demande de réexpédition aurait payé en aval sans récupérer les fonds entrants correspondants. Le correctif autorise la retransmission uniquement tant que l’accusé de réception de l’homologue reste en suspens et force la fermeture du canal lorsque l’homologue affirme qu’une mise à jour déjà reconnue a été manquée.
Parallèlement au correctif de reconnexion LDK, la version 0.2.7 aborde une autre voie de vol impliquant les paiements juste à temps LSPS2, où un service de liquidité ouvre un canal dans le cadre du traitement d’un paiement.
Un paiement intercepté pourrait déformer son montant, ce qui obligerait le service à ouvrir un canal et à transférer plus de Bitcoin que le paiement entrant fourni. Le service couvrirait la différence sur ses fonds propres. Le PR 5042 traite de ce contrôle de montant.
Cette exposition concerne le flux de service LSPS2. Les notes v0.1.13 répertorient le correctif de reconnexion partagé sans répertorier le correctif LSPS2.
Ces défauts diffèrent des bogues de détournement des frais d’épissage et de chargement de l’état enregistré couverts dans le rapport LDK v0.2.6 du 13 septembre de CryptoSlate. Core Lightning est une implémentation distincte, comme décrit dans la mise à jour ci-dessous.
La documentation sur l’architecture de LDK explique que le SDK est compilé et exécuté dans les applications. Les développeurs doivent intégrer le code de bibliothèque corrigé approprié dans le logiciel déployé. Pour les intégrations LSPS2, l’explication de validation PR 5042 indique que les contrats de paiement mis en file d’attente par une version antérieure conservent des montants non validés ; les équipes doivent tenir compte de ces contrats en attente ainsi que mettre à jour la bibliothèque.
