Chargement des prix…
〽️NEUTRAL

Eclair corrige deux failles Lightning BTC qui fuyaient des frais

Deux fusions d'octobre ferment des chemins de fuite de frais dans le dual funding, le splicing et le mode Eclair-signer, mais les correctifs sont postérieurs à la version packagée v0.14.3 : les opérateurs de nœuds doivent donc vérifier leur build.

Eclair, l'implémentation de nœud Lightning d'ACINQ, a fusionné deux correctifs pour des failles pouvant coûter à un nœud des bitcoins via des frais de minage excessifs. Le premier, la PR #3388, plafonne les demandes de replace-by-fee initiées par les pairs lors des ouvertures de canaux à financement double et des splices : auparavant, un pair malveillant pouvait imposer un taux de frais arbitraire à des transactions portant la contribution du portefeuille d'Eclair lui-même, la perte étant versée aux mineurs plutôt qu'à l'attaquant. Le second, la PR #3390, cible le mode Eclair-signer, dans lequel bitcoind construit les transactions tandis qu'Eclair détient les clés. Un backend compromis pouvait signaler des frais dans le budget tout en construisant une transaction qui en payait davantage, par exemple en supprimant l'output de monnaie, puisque selon la comptabilité des transactions Bitcoin, toute valeur d'input non affectée devient des frais de mineur.

Pourquoi c'est important

Les deux failles exploitaient des mécaniques légitimes du protocole plutôt qu'un bug unique, ce qui les rend difficiles à repérer : dans un cas, le nœud paie en connaissance de cause un taux de frais nommé par un pair ; dans l'autre, le chiffre de frais qu'il vérifie est simplement un mensonge. La newsletter du 9 octobre de Bitcoin Optech a signalé les deux changements comme comblant des lacunes de protection dans les configurations de dual funding et de splicing. Elles sont distinctes de la faille de frais de clôture coopérative de septembre et des problèmes de déni de service au redémarrage du 2 octobre.

Impact sur le marché

Les correctifs ont été fusionnés dans master le 2 et le 5 octobre, mais au 12 octobre, la page des versions du projet listait toujours la v0.14.3 de septembre comme dernier build packagé : les correctifs d'octobre lui sont donc postérieurs. Les opérateurs d'Eclair devraient vérifier que leur build installé contient les changements d'octobre, en particulier sur les configurations de dual funding, de splicing ou de signer.

Aucun incident de perte n'est signalé ; les correctifs sont préventifs. L'action concrète à mener est la vérification du build, puisque exécuter le code de la branche master ou attendre la prochaine version taguée est le seul moyen d'obtenir ces protections aujourd'hui.

Tokens associés
$BTC

Questions fréquemment posées

  1. Quelles failles ont été corrigées dans le logiciel Lightning d'Eclair ?

    Deux vulnérabilités de fuite de frais : un chemin de replace-by-fee non plafonné lors des ouvertures de canaux à financement double et des splices, et une lacune du mode Eclair-signer où un backend Bitcoin Core compromis pouvait construire des transactions payant plus que les frais déclarés.

  2. Comment un pair malveillant pouvait-il voler un nœud Eclair via les frais ?

    Lors d'une ouverture de canal à financement double ou d'un splice, le pair pouvait demander une transaction de remplacement à un taux de frais arbitraire, et Eclair payait sa propre contribution de portefeuille à ce taux, sans plafond. La perte allait aux mineurs sous forme de frais plutôt qu'à l'attaquant.

  3. Quelle est la faille du mode Eclair-signer (PR #3390) ?

    bitcoind sélectionne les coins et construit les transactions tandis qu'Eclair conserve les clés de signature. Un backend compromis pouvait signaler des frais dans le budget tout en construisant une transaction qui en payait davantage, notamment en supprimant l'output de monnaie, puisque toute valeur d'input non…

  4. Quelle version d'Eclair contient les correctifs de frais d'octobre ?

    Au 12 octobre, les correctifs n'existaient que dans la branche master, fusionnés les 2 et 5 octobre. La dernière version packagée, la v0.14.3 de septembre, est antérieure aux deux réparations : les opérateurs doivent donc vérifier que leur build installé contient les changements d'octobre.

  5. Des nœuds Eclair ont-ils réellement été vidés par ces failles ?

    Aucun incident de perte n'est signalé. La newsletter du 9 octobre de Bitcoin Optech a présenté les deux changements comme comblant des lacunes de protection, et les correctifs sont préventifs plutôt qu'une réponse à un exploit connu.

Attribution de la source
Agrégé de CryptoSlate · Vérifié · Dernière mise à jour il y a 10d
Ouvrir l'original →