Core Lightning v26.06.10 corrige un bug de vidage de canal et des failles d’accès à distance

Les mainteneurs de Core Lightning ont publié la version 26.06.10 le 4 novembre pour remédier à des failles de sécurité des canaux, de résolution des paiements et d’accès à distance dans le logiciel de nœud Lightning Bitcoin. La mise à jour inclut une correction pour un bug de vidage de canal qui permettait aux pairs de réduire le solde du nœud en frais lors de fermetures forcées, ainsi que de nouvelles vérifications de signatures pour les opérations de canaux à financement dual.

Sécurité des canaux et corrections des paiements

Cette publication ajoute la vérification des signatures de transactions d’un pair lors de l’ouverture et de l’épissage de canaux Bitcoin à financement dual, conformément à la spécification BOLT 2 du protocole Lightning. Ce changement garantit que les nœuds valident correctement les actions des pairs lors de ces processus expérimentaux.

Une correction critique traite d’un problème où un contrat à verrouillage temporel haché (HTLC) supprimé pouvait être confondu avec un HTLC actif partageant le même hachage de paiement, le même montant et la même date d’expiration. Dans la version précédente, cette confusion pouvait provoquer l’échec d’un paiement en amont, bien que le pair puisse toujours réclamer les fonds. La nouvelle version résout cette erreur de résolution des paiements.

Les mainteneurs ont également introduit une limite sur les seuils de poussière des canaux. Le logiciel rejette désormais les ouvertures de canal lorsqu’un pair propose une limite de poussière supérieure à 5 000 satoshis. Le journal des modifications note que le comportement précédent permettait à un pair malveillant ou défectueux de réduire le solde du nœud en frais lors d’une fermeture forcée. Pour les ouvertures à financement dual, le logiciel rejette également la limite de poussière d’un pair si elle dépasse la réserve du canal.

Le financement dual reste une fonctionnalité expérimentale, et les mainteneurs continuent de décourager l’utilisation de canaux sans confirmation avec des pairs non fiables. La publication refuse les ouvertures sans confirmation v2 à moins que l’opérateur n’ait explicitement configuré l’acceptation pour ce pair spécifique. De plus, les nœuds ayant exécuté la branche master ne peuvent pas rétrograder vers la série 26.06.x car leur schéma de base de données est plus récent.

Gestion des commandes à distance et des identifiants

La mise à jour traite également des failles dans l’interface commando, qui permet aux pairs directement connectés de demander à un nœud d’exécuter des commandes spécifiques. Ces requêtes nécessitent généralement une rune, un identifiant d’autorisation qui permet la commande. La nouvelle version empêche le contournement des restrictions de runes pname en utilisant des noms de paramètres dupliqués ou des variantes de ponctuation.

Les autres corrections incluent la résolution d’un plantage de commando causé par la réutilisation d’un identifiant de commande après une commande échouée et le rejet de runes surdimensionnées pour éviter un travail de décodage excessif. Les mainteneurs recommandent aux opérateurs de lier les runes utilisées via commando à l’identifiant de nœud de l’application autorisée. Ils conseillent également de mettre sur liste noire les runes que les opérateurs ne peuvent pas justifier en utilisant la fonction blacklistrune et de les remplacer par des identifiants plus strictement restreints.

Les mainteneurs ont temporairement retenu les tests de correction de sécurité pour ralentir la conversion des correctifs en exploits fonctionnels, donnant plus de temps aux opérateurs pour mettre à niveau. La publication suit les correctifs de sécurité de la v26.06.9 et un plantage de déclencheur stocké signalé le 2 novembre. GitHub affiche une date de publication du 4 novembre pour la v26.06.10, tandis que le journal des modifications étiqueté date la même version du 5 novembre.