Core Lightning, l'une des principales implémentations logicielles utilisées pour faire fonctionner les nœuds de paiement Lightning de Bitcoin, a publié la version 26.06.10 avec une nouvelle série de correctifs de sécurité, et ses mainteneurs demandent à tous les utilisateurs de procéder à la mise à niveau dès que possible. La mise à jour accompagne le correctif logiciel d'une seconde tâche pour les opérateurs : examiner les identifiants permettant les commandes à distance sur leurs nœuds, une étape décrite par les mainteneurs comme distincte de l'installation de la nouvelle version. Elle combine le durcissement du plugin qui gère les commandes à distance avec des modifications de la manière dont les nœuds évaluent les ouvertures de canaux et les conditions de paiement.

Il s'agit de la troisième version ponctuelle consécutive publiée sans période d'embargo. Les versions 26.06.8 et 26.06.9 ont suivi la même approche, les correctifs ayant été rendus publics immédiatement. Comme pour ces publications, les mainteneurs ont de nouveau retenu les tests liés aux correctifs de sécurité. Selon les notes de version, cela rend plus difficile la transformation des correctifs en exploits fonctionnels et donne aux utilisateurs plus de temps pour se mettre à niveau. Ce modèle de divulgation définit également les enjeux pour les opérateurs : une fois la publication rendue publique, les failles qu'elle corrige le sont aussi, ce qui signifie qu'un nœud en retard exécute un logiciel présentant des failles documentées.

Audit des identifiants ajouté à la liste des tâches de mise à niveau

Les runes et commando sont au cœur du travail de sécurité de cette mise à jour. Commando permet à un pair directement connecté de demander à un nœud d'exécuter une commande, et le pair a généralement besoin d'une rune — un identifiant d'autorisation — pour ce faire.

La mise à jour ferme une méthode de contournement des limites de rune sur les noms de paramètres via des noms dupliqués ou à variantes de ponctuation. Elle corrige également un crash de commando causé par la réutilisation d'un identifiant de commande après l'échec d'une commande. Les runes surdimensionnées sont désormais rejetées sans appel ; auparavant, le logiciel pouvait passer un temps quadratique à les décoder.

Les mainteneurs recommandent de lier chaque rune utilisée via commando à l'identifiant de nœud de l'application qui l'utilise. Avec cette restriction d'id en place, la rune ne peut pas être utilisée depuis ailleurs. Les opérateurs sont également invités à mettre en liste noire toute rune qu'ils ne peuvent pas justifier à l'aide de la commande blacklistrune, puis à émettre de nouvelles runes avec des restrictions plus strictes. Prises ensemble, ces étapes équivalent à un audit de chaque identifiant pouvant déclencher des commandes à distance sur un nœud, les runes inexpliquées étant révoquées avant l'émission des remplacements.

Correctifs de canaux et de paiements

La nouvelle version vérifie les signatures de transaction d'un pair lors de l'ouverture de canaux à financement double et lors du splicing, l'opération qui ajuste les fonds d'un canal sans le fermer. Cela conforme à la spécification BOLT 2 du protocole Lightning, qui couvre l'établissement des canaux et le fonctionnement normal pair à pair, selon le changelog.

Un autre correctif concerne un contrat de paiement conditionnel appelé HTLC. Un HTLC venant d'être supprimé pouvait être confondu avec un HTLC actif partageant son hash de paiement, son montant et son expiration, ce qui amenaient le nœud à faire échouer le paiement actif tandis que son pair pouvait encore le réclamer.

La gestion des ouvertures de canaux est également plus stricte. Les nœuds refusent désormais les ouvertures de canaux lorsqu'un pair propose une limite de dust — le seuil en dessous duquel les sorties sont considérées comme de la poussière — supérieure à 5 000 satoshis ; le changelog indique que l'ancien comportement permettait à un pair de fondre le solde du nœud en frais lors d'une fermeture forcée. Pour les ouvertures à financement double, une limite de dust d'un pair supérieure à la réserve du canal est également refusée, et une ouverture v2 à confirmation zéro — un canal qui devient actif avant la confirmation de sa transaction de financement — est refusée, sauf si l'opérateur a configuré le nœud pour en accepter une de ce pair. Le financement double reste expérimental, et les mainteneurs déconseillent les canaux à confirmation zéro avec des pairs de confiance incertaine.

D'autres changements apportent une réponse par défaut sûre lorsqu'un hook de plugin échoue, au lieu d'un crash ou d'un blocage. Les hausses de frais de splice utilisent désormais au moins 25/24 du taux de frais précédent, ce que des pairs tels qu'Eclair exigent. Les nœuds ayant exécuté des builds de développement 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. La publication fournit des binaires reproductibles pour Ubuntu 22.04, 24.04 et 26.04, ainsi que des images Docker.

Divulgation et calendrier de publication

Les failles corrigées dans cette version ont été signalées par près de 20 sources nommées, dont The Bitcoin Red Team, Matt Morehouse et Niklas Gögge. D'autres ont demandé à ne pas être nommées.

GitHub indique une date de publication au 4 novembre pour la version, tandis que son changelog balisé indique le 5 novembre. La mise à jour fait suite à un crash distinct à déclencheur stocké divulgué le 2 novembre. Au moment de la rédaction, le bitcoin se négociait autour de 76 002 $, en baisse de 5,29 % sur 24 heures.