Une faille de Core Lightning peut garder les nœuds en plantage après une mise à jour tant que le déclencheur stocké n'est pas supprimé

Une faille divulguée dans Core Lightning, le logiciel du réseau de paiement Lightning de Bitcoin, peut laisser un nœud planter à chaque redémarrage même après une mise à jour, car l'annonce malveillante à l'origine du plantage reste stockée sur disque.

Le chercheur Nishant Bansal a divulgué le problème le 24 octobre, identifiant les versions v25.02 à v26.04 comme affectées. Une fois l'annonce enregistrée, chaque redémarrage recharge le même déclencheur, et Bansal indique que l'opérateur doit supprimer manuellement l'enregistrement fautif pour restaurer le nœud.

Bitcoin Optech, une newsletter technique qui suit les développements d'ingénierie de Bitcoin, a mis en évidence le problème le 30 octobre, mais le correctif préventif date de plusieurs mois. Core Lightning a fusionné la pull request #9082 le 24 avril et livré le correctif dans la version v26.04.1 le 25 avril. La divulgation d'octobre explique donc une faille dont le correctif préventif était disponible depuis avril.

Pourquoi le correctif ne supprime pas un déclencheur stocké

Les annonces de canal informent les nœuds des connexions dans le graphe de routage Lightning. Les paiements passent par ces connexions enregistrées, si bien que chaque nœud de routage dépend d'une copie exacte du graphe pour déplacer les fonds. Dans ce cas, une annonce forgée désignait le même nœud jusque-là inconnu aux deux extrémités. Le logiciel vulnérable l'a acceptée, l'a écrite dans le gossip_store sur disque, puis l'a chargée dans le graphe de routage.

Le graphe a alors tenté d'insérer ce nœud deux fois. Un dispositif de protection contre les doublons a fait échouer gossipd, le composant qui gère ces annonces, et Core Lightning a considéré cet échec comme fatal pour l'ensemble du nœud.

Le correctif vérifie l'ordre des extrémités avant d'accepter une annonce. Exiger que le premier identifiant de nœud soit strictement inférieur au second rejette également les identifiants identiques, empêchant ainsi l'entrée malformée d'être acceptée et stockée.

La validation ne s'applique toutefois qu'aux annonces entrantes. Le démarrage lit toujours les enregistrements déjà présents dans le gossip_store, et la mise à jour ne supprime pas un enregistrement malveillant sauvegardé avant le plantage. C'est pourquoi la mesure de récupération exigée par Bansal est la suppression manuelle de l'enregistrement malveillant du gossip_store.

Le nettoyage seul laisse également une installation vulnérable exposée à un nouveau plantage : selon la divulgation, un attaquant peut renvoyer la même annonce tant que la sortie de financement qu'il contrôle — la sortie on-chain qui a ouvert le canal — reste non dépensée.

Exposition via le relais, conseils de mise à jour et risque d'interruption

Bitcoin Optech note que les versions de Core Lightning antérieures à la v25.02 pouvaient accepter et relayer de telles annonces sans planter elles-mêmes. Un attaquant n'avait donc pas besoin d'une connexion directe à chaque nœud vulnérable, puisqu'une annonce relayée est transmise aux pairs de chaque nœud et peut propager l'enregistrement malformé plus profondément dans le réseau.

Pour les opérateurs choisissant de mettre à jour maintenant, la v26.04.1 constitue la première version contenant le correctif de ce défaut. Au 2 novembre, la dernière version du projet est la v26.06.9, publiée le 7 octobre, que les mainteneurs recommandent fortement d'installer.

L'interruption de service comporte un risque de surveillance des paiements au-delà de la simple indisponibilité. Dans Lightning, l'application des règles des canaux incombe à l'opérateur du nœud. Bansal avertit qu'un nœud hors ligne ne peut pas surveiller la chaîne pour détecter un état de canal révoqué ou une demande de paiement limitée dans le temps qui doit être effectuée avant l'expiration. Manquer ces événements peut mettre les fonds en danger.

Reportage original : CryptoSlate