Eclair v0.14.4 d'ACINQ empêche les pages web malveillantes d'envoyer des commandes authentifiées à un nœud Bitcoin Lightning via le navigateur d'un opérateur. La faille exigeait qu'une API Eclair soit activée et atteignable par le navigateur, avec des identifiants HTTP Basic déjà mis en cache pour cette API. La version a été publiée le 15 octobre, et les mainteneurs recommandent de mettre à niveau puis de redémarrer le nœud sans fermer ses canaux Lightning.
Pourquoi c'est important
Une page web malveillante pouvait soumettre un simple formulaire HTML à l'API d'Eclair, ce qui amenait le navigateur à joindre automatiquement les identifiants enregistrés. Bien que l'attaquant ne puisse pas lire la réponse, la commande authentifiée atteignait tout de même le nœud. L'API d'Eclair peut exposer l'état du nœud, ouvrir et fermer des canaux, et envoyer ou recevoir des paiements, ce qui fait du passage par le navigateur un risque opérationnel significatif.
La version 0.14.4 rejette avec HTTP 403 les requêtes API comportant un en-tête Origin avant l'exécution de la route API, quelle que soit la valeur de cet en-tête. La modification affecte aussi les interfaces légitimes basées sur un navigateur, y compris les frontends hébergés sur la même origine. Ces interfaces ont désormais besoin d'un intermédiaire backend entre le navigateur et Eclair.
Impact sur le marché
Le correctif n'interrompt pas l'accès en ligne de commande classique. Les mainteneurs indiquent que curl et eclair-cli n'envoient pas l'en-tête Origin, donc les requêtes normales émises par ces outils continuent de fonctionner. Le patch a été fusionné le 15 septembre dans la pull request #3380 et est livré avec des réparations liées aux funding-fee et au signer.
La vérification de l'en-tête Origin ne remplace pas l'authentification ni les contrôles réseau. Un client non-navigateur peut omettre cet en-tête, donc Eclair recommande de lier l'API à la boucle locale et de limiter l'accès à la machine locale. Les opérateurs de nœuds Lightning doivent mettre à niveau, conserver ces restrictions et examiner tout outil exposé à un navigateur avant de le reconnecter via un backend.
Questions fréquemment posées
-
Qu'a corrigé Eclair v0.14.4 pour les opérateurs de nœuds Lightning ?
Elle empêche les pages web malveillantes d'envoyer des commandes authentifiées à un nœud Lightning Eclair via le navigateur de l'opérateur en rejetant les requêtes comportant un en-tête Origin.
-
Quelles conditions étaient requises pour l'attaque par navigateur ?
L'API Eclair devait être activée et atteignable par le navigateur de l'opérateur, avec des identifiants HTTP Basic déjà mis en cache dans ce navigateur.
-
Quelles commandes le passage par le navigateur pouvait-il atteindre ?
L'API d'Eclair peut lire l'état du nœud, ouvrir et fermer des canaux, et envoyer ou recevoir des paiements, de sorte que des commandes authentifiées pouvaient affecter des opérations importantes du nœud.
-
Est-ce que curl et eclair-cli cessent de fonctionner après le patch ?
Non. Les mainteneurs indiquent que curl et eclair-cli n'envoient pas l'en-tête Origin, donc leurs requêtes API ordinaires continuent de fonctionner.
-
Pourquoi la liaison en boucle locale et l'authentification restent-elles nécessaires ?
La vérification de l'en-tête Origin n'est pas un système d'autorisation car les clients non-navigateur peuvent omettre cet en-tête. Eclair recommande de garder l'API liée à la boucle locale et de maintenir l'authentification ainsi que les restrictions réseau.