Lightning Development Kit, une boîte à outils pour créer des applications Bitcoin Lightning, a publié la version 0.2.6 le 9 septembre avec des correctifs pour des bogues qui pourraient détourner de petites quantités de fonds d’un nœud ou empêcher le chargement de l’état du canal enregistré.
LDK propose une implémentation Lightning sous forme de kit de développement logiciel pour des utilisations telles que les portefeuilles mobiles et l’infrastructure de services de paiement. La mise à jour offre aux développeurs qui gèrent les applications concernées des correctifs pour un risque financier et une condition pouvant perturber le redémarrage normal des nœuds.
Une épissure permet à un nœud d’ajouter ou de supprimer des fonds d’un canal de paiement existant. La documentation de l’API de LDK décrit cela comme une dépense du financement de la chaîne et son remplacement par un nouveau. Concrètement, cela modifie l’argent engagé dans la chaîne via une opération de financement de remplacement.
Cette transaction comporte des coûts partagés entre les participants. Le nœud initiateur paie des frais pour les parties communes spécifiées, ainsi que pour ses propres entrées et sorties. Le calcul des frais affecte donc la part de l’argent du nœud qui sert à financer l’opération.
La faille d’épissage pourrait permettre à un homologue malveillant de provoquer une allocation de frais excessive, l’excédent étant reversé à la sortie de cet homologue. Le communiqué décrit une petite quantité de fonds à risque lorsqu’un nœud lance une épissure, sans spécifier de plafond numérique.
La faille de sécurité distincte impliquait deux contrats de paiement partageant le même hachage de paiement. Après que l’un ait été transféré avec succès, la réception et le rejet immédiat d’un faux pourraient laisser l’état ChannelManager incapable de se charger.
ChannelManager est le composant de LDK permettant de gérer les canaux et les paiements. Le redémarrage d’un nœud existant implique la lecture de son état enregistré en mémoire, un processus appelé désérialisation. Si cet état enregistré est rejeté lors du chargement, l’application ne peut pas terminer son redémarrage normal. Le rejet du faux paiement n’évite pas, en soi, cet échec particulier.
Pour les constructeurs de portefeuilles, les deux correctifs concernent différents aspects du maintien d’un service de paiement : l’allocation correcte des fonds lorsqu’un canal change et le maintien de l’état qui peut être chargé après un arrêt.
La documentation sur l’architecture de LDK explique que son implémentation principale est compilée en applications. Les développeurs choisissent les composants de stockage, de portefeuille, de réseau et de surveillance de la blockchain environnants. L’intégration de la boîte à outils corrigée dans ces applications constitue donc l’étape de maintenance pertinente pour les intégrations concernées.
L’avis de publication ne signale aucune perte observée ni application exploitée. Sa description établit les vulnérabilités et les correctifs, plutôt qu’un bilan mesuré pour les utilisateurs. Avec la version 0.2.6 disponible, la tâche immédiate des équipes chargées des applications concernées est d’intégrer ces correctifs dans les logiciels qu’elles exploitent.
