Une faille d’Eclair, une implémentation de Bitcoin Lightning, pourrait permettre à un pair malveillant de faire planter un nœud non corrigé sans financer de canal ni payer de frais de transaction on-chain. Les nœuds sous v0.14.0 ou une version antérieure étaient concernés. Dans une preuve de concept sur regtest, le chercheur Erick Cestari a saturé un tas Java de 4 GB en environ 47 minutes et 43 secondes, après l’accumulation de 217 623 lignes dans la base de données des canaux. Ces enregistrements sont restés sur le disque, provoquant un nouvel épuisement de la mémoire au démarrage du nœud.
Pourquoi c’est important
Eclair limitait le nombre de canaux en attente qu’un pair pouvait ouvrir, mais des vérifications incohérentes des identifiants temporaires et définitifs des canaux conduisaient son compteur à sous-estimer les canaux non financés. Un attaquant pouvait ainsi accumuler des demandes sauvegardées, au prix d’une consommation de mémoire et de ressources de la base de données pour le nœud. L’attaque nécessitait toujours des ressources de calcul et du trafic réseau, mais pas les BTC normalement engagés pour financer un canal.
La preuve de concept montre une indisponibilité persistante sur un nœud vulnérable, et non une exploitation en conditions réelles ni le nombre d’opérateurs touchés. Le délai avant le plantage mesuré en laboratoire n’est pas une référence universelle. La faille a été corrigée dans v0.14.1, publiée en juillet avant sa divulgation publique.
Impact sur le marché
Cette découverte concerne la disponibilité des nœuds Lightning, et non une perte de fonds avérée. Une autre faille liée à une condition de concurrence lors de l’ouverture de canaux, également corrigée dans v0.14.1, laissait des processus orphelins consommer des ressources. Le nœud testé se remettait de cette faille après une déconnexion ou un redémarrage. Ce rétablissement ne s’applique pas à la saturation persistante de la base de données.
ACINQ recommande de passer à v0.14.3 pour corriger d’autres vulnérabilités de sécurité. Les opérateurs dont la base de données est déjà surchargée doivent entreprendre une remise en état distincte : Cestari cite l’augmentation du tas mémoire ou la suppression manuelle des faux enregistrements de canaux comme mesures possibles. Redémarrer le nœud à répétition n’efface pas ces enregistrements.
Questions fréquemment posées
-
Pourquoi le redémarrage d’un nœud Eclair touché peut-il ne pas rétablir le service ?
Les enregistrements de canaux non financés restent dans la base de données. Eclair peut de nouveau épuiser la mémoire en les rechargeant au démarrage.
-
L’attaque causant des plantages persistants exige-t-elle de financer un canal Bitcoin Lightning ?
Non. Un pair malveillant pouvait accumuler des demandes de canaux sauvegardées sans diffuser de transaction de financement ni payer de frais on-chain, même si l’attaque nécessitait des ressources de calcul et du trafic réseau.
-
Quelles versions d’Eclair étaient touchées et laquelle a corrigé la faille ?
La faille causant des plantages persistants touchait les nœuds joignables sous v0.14.0 ou une version antérieure. Elle a été corrigée dans v0.14.1, publiée en juillet avant sa divulgation publique.
-
Qu’a montré la preuve de concept sur Eclair ?
Sur regtest, elle a saturé un tas Java de 4 GB en environ 47 minutes et 43 secondes, après l’accumulation de 217 623 lignes dans la base de données des canaux. Elle n’a établi ni une exploitation réelle ni un délai de panne universel.
-
Pourquoi ACINQ recommande-t-il v0.14.3 si v0.14.1 a corrigé ces failles de déni de service ?
La version v0.14.3 corrige d’autres vulnérabilités de sécurité. Le correctif de v0.14.1 pour les deux failles de déni de service ne constitue pas à lui seul une recommandation de sécurité suffisante aujourd’hui.
WuBlockchain
CoinTelegraph
CZ Binance
Glassnode
Crypto Capital Venture
WatcherGuru