A Eclair, implementação de nós Lightning da ACINQ, integrou duas correções para falhas que podiam custar a um nó Bitcoin através de taxas de mineração excessivas. A primeira, o PR #3388, limita as exigências de replace-by-fee iniciadas pelo peer durante aberturas de canais com dual funding e splices: anteriormente, um peer malicioso podia impor uma taxa arbitrária a transações que incluíam a contribuição da própria carteira da Eclair, com a perda paga aos mineradores e não ao atacante. A segunda, o PR #3390, incide sobre o modo Eclair-signer, em que o bitcoind constrói as transações enquanto a Eclair mantém as chaves. Um backend comprometido podia reportar uma taxa dentro do orçamento enquanto construía uma transação que na verdade pagava mais, por exemplo eliminando o output de troco, já que na contabilidade de transações do Bitcoin qualquer valor de input não atribuído se torna taxa de minerador.
Porque é importante
Ambas as lacunas exploravam mecânicas legítimas do protocolo em vez de um único bug, o que as torna difíceis de detetar: num caso o node paga conscientemente uma taxa indicada pelo peer, no outro o valor da taxa que verifica é simplesmente mentira. O boletim de 9 de outubro da Bitcoin Optech assinalou ambas as alterações como fecho de lacunas de proteção em configurações de dual funding e splicing. São distintas da falha de taxas no fecho cooperativo de setembro e dos problemas de denial-of-service por reinício de 2 de outubro.
Impacto no mercado
As correções foram integradas no master a 2 e 5 de outubro, mas, até 12 de outubro, a página de releases do projeto ainda listava a v0.14.3 de setembro como o build empacotado mais recente, pelo que as correções de outubro são posteriores. Os operadores da Eclair devem verificar se o build instalado contém as alterações de outubro, sobretudo em configurações de dual funding, splicing ou signer.
Não há eventos de perda reportados; as correções são preventivas. A ação prática é a verificação do build, uma vez que correr código do branch master ou esperar pelo próximo release marcado é hoje a única forma de obter essas proteções.
Perguntas frequentes
-
Que falhas foram corrigidas no software Lightning da Eclair?
Duas vulnerabilidades de drenagem de taxas: um caminho de replace-by-fee sem limites durante aberturas de canais com dual funding e splices, e uma lacuna no modo Eclair-signer em que um backend Bitcoin Core comprometido podia construir transações que pagavam mais do que a taxa reportada.
-
Como podia um peer malicioso roubar de um nó Eclair através de taxas?
Durante uma abertura de canal com dual funding ou um splice, o peer podia pedir uma transação de substituição a uma taxa arbitrária, e a Eclair pagava a sua própria contribuição de carteira a essa taxa sem limite superior. A perda ia para os mineradores como taxas e não para o atacante.
-
Qual é a falha do modo Eclair-signer (PR #3390)?
O bitcoind seleciona as moedas e constrói as transações enquanto a Eclair mantém as chaves de assinatura. Um backend comprometido podia reportar uma taxa dentro do orçamento enquanto construía uma transação que na verdade pagava mais, incluindo eliminando o output de troco, já que o valor de input não atribuído se…
-
Que versão da Eclair contém as correções de taxas de outubro?
Até 12 de outubro, as correções existiam apenas no branch master, integradas a 2 e 5 de outubro. O release empacotado mais recente, a v0.14.3 de setembro, é anterior a ambas as reparações, pelo que os operadores devem verificar se o build instalado contém as alterações de outubro.
-
Algum nó Eclair foi efetivamente drenado por estas falhas?
Não há eventos de perda reportados. O boletim de 9 de outubro da Bitcoin Optech destacou ambas as alterações como fecho de lacunas de proteção, e as correções são preventivas em vez de uma resposta a um exploit conhecido.
CoinDesk
Glassnode
WatcherGuru
Altcoin Daily
CoinTelegraph
Crypto Capital Venture