Explorar o relâmpago foi a escolha ética

Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e host de podcast Bitcoin orientado para tecnologia.

Pela segunda vez em aproximadamente um mês, o btcd/LND teve um bug explorado que fez com que eles se desviassem do consenso do Bitcoin Core. Mais uma vez, Burak foi o desenvolvedor que desencadeou esta vulnerabilidade – desta vez foi claramente intencional – e mais uma vez, foi um problema com o código para analisar transações Bitcoin acima da camada de consenso. Como discuti em meu peça sobre o bug anterior que Burak acionou, antes do Taproot havia limites para o tamanho do script e dos dados de testemunha em uma transação. Com a ativação do Taproot, esses limites foram removidos, deixando apenas as limitações do próprio limite de tamanho do bloco para limitar essas partes das transações individuais. O problema com o último bug foi que, apesar do código de consenso no btcd ter sido atualizado adequadamente para refletir essa mudança, o código que trata a transmissão ponto a ponto – incluindo a análise de dados antes do envio ou recebimento – não foi atualizado corretamente. Portanto, os blocos e transações de processamento de código antes de serem validados para consenso falharam nos dados, nunca os passaram para a lógica de validação de consenso e o bloco em questão nunca foi validado.

Uma coisa muito semelhante aconteceu desta vez. Outro limite na seção ponto a ponto da base de código era impor incorretamente uma restrição aos dados testemunhas, limitando-os a um máximo de 1/8 do tamanho do bloco, em oposição ao tamanho total do bloco. Burak elaborou um transação com dados de testemunha apenas uma única unidade de peso acima do limite estrito e mais uma vez paralisou os nós BTCD e LND naquela altura do bloco. Esta transação foi uma transação fora do padrão, o que significa que, embora seja perfeitamente válida pelas regras de consenso, não é válida de acordo com a política padrão do mempool e, portanto, os nós não a transmitirão pela rede. É perfeitamente possível extraí-lo em um bloco, mas a única maneira de fazer isso é fornecê-lo diretamente a um minerador, que foi o que Burak fez com a ajuda do F2Pool.

Isso realmente deixa claro que qualquer pedaço de código cujo objetivo seja analisar e validar dados do Bitcoin deve ser fortemente auditado para garantir que esteja alinhado com o que o Bitcoin Core fará. Não importa se esse código é o mecanismo de consenso para a implementação de um nó ou apenas um trecho de código que transmite transações para um nó do Lightning. Este segundo bug foi literalmente logo acima do do mês passado na base de código. Nem foi descoberto por ninguém do Lightning Labs. AJ Towns relatou isso em 11 de outubro, dois dias após o bug original ter sido acionado pela transação multisig 998 de 999 de Burak. Foi postado publicamente no Github por 10 horas antes de ser excluído. Uma correção foi então feita, mas não lançada, com a intenção de corrigir discretamente o problema na próxima versão do LND.

Agora, este é um procedimento bastante padrão para uma vulnerabilidade séria, especialmente com um projeto como o Bitcoin Core, onde tal vulnerabilidade pode realmente causar sérios danos à rede/protocolo da camada base. Mas neste caso específico, representava um sério risco para os fundos dos utilizadores do LND, e dado o facto de estar literalmente ao lado do bug anterior que apresentava os mesmos riscos, as probabilidades de ser encontrado e explorado eram muito elevadas, como demonstrado por Burak. Isso levanta a questão de saber se a abordagem de correção silenciosa é o caminho a seguir quando se trata de vulnerabilidades como essa, que podem deixar os usuários vulneráveis ​​ao roubo de fundos (porque seu nó fica incapaz de detectar estados antigos de canais e penalizá-los adequadamente).

Como abordei em meu artigo sobre o último bug, se um agente mal-intencionado tivesse encontrado os bugs antes de um desenvolvedor bem-intencionado, ele poderia ter aberto taticamente novos canais para nós vulneráveis, roteado todo o conteúdo desses canais de volta para si mesmo e então explorou o bug. A partir daí, eles teriam esses recursos sob seu controle e também poderiam fechar o canal com o estado inicial, literalmente dobrando seu dinheiro. O que Burak fez ao explorar ativamente esse problema de forma irônica, na verdade protegeu os usuários do LND contra tal ataque.

Uma vez explorado, os usuários estavam abertos a tais ataques de pares pré-existentes com os quais já tinham canais abertos, mas não eram mais capazes de serem alvos específicos de novos canais. Seus nós estavam paralisados ​​e nunca reconheceriam ou processariam pagamentos por meio de canais que alguém tentasse abrir após o bloqueio que travou seu nó. Portanto, embora não tenha eliminado completamente o risco de exploração dos usuários, limitou esse risco às pessoas com quem já tinham um canal. A ação de Burak mitigou isso. Pessoalmente, acho que esse tipo de ação em resposta ao bug fazia sentido; limitou os danos, conscientizou os usuários sobre o risco e fez com que fosse rapidamente corrigido.

O LND também não foi a única coisa afetada. Líquido o processo de vinculação também foi interrompido, exigindo atualizações dos funcionários da federação para corrigi-lo. Versões antigas de Rust Bitcoin também foram afetados, o que fez com que a paralisação afetasse alguns exploradores de bloco e instâncias electrs (uma implementação do servidor backend para Electrum Wallet). Agora, com exceção da indexação da Liquid que eventualmente expôs fundos às chaves de recuperação de emergência mantidas pela Blockstream após o término do timelock - e, realisticamente, na trama do filme estilo assalto em que a Blockstream roubou esses fundos, todos sabem exatamente quem perseguir - esses outros questões nunca colocam os fundos de ninguém em risco em nenhum momento. Além disso, Rust Bitcoin corrigiu esse bug específico em versões mais recentes, o que aparentemente não levou a nenhuma comunicação com os mantenedores de outras bases de código para destacar o potencial para tais problemas. Foi apenas a exploração ativa do bug ao vivo na rede que expôs amplamente que o problema existia em várias bases de código.

Isso levanta alguns grandes problemas quando se trata de vulnerabilidades como essa no software da Camada 2 no Bitcoin. Primeiro, a seriedade com que essas bases de código são auditadas em busca de bugs de segurança e como isso é priorizado em relação à integração de novos recursos. Acho muito revelador que a segurança nem sempre é priorizada, visto que esse segundo bug nem foi encontrado pelos mantenedores da base de código onde estava presente, embora estivesse literalmente ao lado do bug inicial descoberto no mês passado. Depois de um grande bug que colocou os fundos dos usuários em risco, nenhuma auditoria interna dessa base de código foi feita? Foi preciso alguém de fora do projeto para descobri-lo? Isso não demonstra uma prioridade para salvaguardar os fundos dos utilizadores em vez de criar novas funcionalidades para atrair mais utilizadores. Em segundo lugar, o fato de esse problema já ter sido corrigido no Rust Bitcoin demonstra uma falta de comunicação entre os mantenedores de diferentes bases de código em relação a bugs como esse. Isso é bastante compreensível, já que bases de código completamente diferentes não fazem alguém que encontrou um bug em uma delas pensar imediatamente: “Eu deveria entrar em contato com outras equipes que escrevem software semelhante em linguagens de programação totalmente diferentes para alertá-las sobre o potencial de tal bug”. Você não encontra um bug no Windows e imediatamente pensa em reportar o bug aos mantenedores do kernel do Linux. No entanto, o Bitcoin como protocolo para consenso distribuído em uma rede global é uma fera muito diferente; talvez os desenvolvedores de Bitcoin devessem começar a pensar nesse sentido quando se trata de vulnerabilidades no software Bitcoin. Especialmente quando se trata de analisar e interpretar dados relacionados ao consenso.

Por último, talvez quando se trata de protocolos como o Lightning, que dependem da observação do blockchain em todos os momentos para poder reagir aos estados antigos do canal, a fim de manter a segurança, a análise independente e a verificação dos dados devem ser mantidas em um mínimo absoluto - se não removido totalmente e delegado ao Bitcoin Core ou dados diretamente derivados dele. Core Lightning é arquitetado desta forma, conectando-se a uma instância do Bitcoin Core e dependendo inteiramente dela para validação de blocos e transações. Se o LND funcionasse da mesma maneira, nenhum desses bugs no btcd teria afetado os usuários do LND de uma forma que colocasse seus fundos em risco.

Qualquer que seja a maneira como as coisas são tratadas – terceirizando totalmente a validação ou simplesmente minimizando a validação interna e abordando-a com muito mais cuidado – esse incidente mostra que algo precisa mudar na abordagem da questão de como o software da Camada 2 lida com a interação com dados relacionados ao consenso. Mais uma vez, todos tiveram muita sorte de que isso não tenha sido explorado por um ator mal-intencionado, mas sim por um desenvolvedor que provou seu ponto de vista. Dito isto, o Bitcoin não pode contar com sorte ou esperar que não existam atores maliciosos.

Os desenvolvedores e usuários devem se concentrar em melhorar os processos para evitar que incidentes como esse aconteçam novamente, e não em jogar a culpa como se fosse uma batata quente.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.