A esta altura você já deve ter lido ou escutado por aí que os desenvolvedores da principal implementação do software do Bitcoin encontraram não apenas um, mas dois seríssimos bugs no código do protocolo que dita as regras de funcionamento do ativo digital mais valioso do planeta.
Se você não ficou sabendo de nada, segue abaixo um breve resumo do que aconteceu. Se você sabe do que estou falando, pule a explicação e siga direto para a análise do meu amigo e mestre das linhas de código Hamilton Amorim, o Algorista.
Bug? Que bug?
No dia 17 de setembro, uma pessoa anônima — que mais tarde viria a se identificar como um desenvolvedor do Bitcoin Cash, ou seja, um programador que trabalha naquele que talvez seja o principal concorrente do Bitcoin — comunicou aos desenvolvedores do software Bitcoin Core a existência de duas vulnerabilidades que poderiam causar danos significativos.
Em menos de 10 horas, os desenvolvedores do Bitcoin Core conseguiram identificar, consertar e liberar para download e upgrade uma nova versão do software do Bitcoin. Basicamente, um dos bugs encontrados poderia, se explorado com sucesso por um hacker malicioso, inflacionar a quantidade de unidades de bitcoin.
Para quem não se lembra, o limite de emissão de Bitcoin, que foi instituído por Satoshi Nakamoto, é de praticamente 21 milhões de unidades. Muitas pessoas acreditam que boa parte do valor inerente à tecnologia do Bitcoin deriva do fato dele ser um ativo escasso cuja emissão é matematicamente previsível, pois segue regras rígidas estipuladas no código do protocolo. É esta característica que faz o Bitcoin ser, por exemplo, comparado ao ouro.
Além do bug que poderia inflacionar a oferta de bitcoin, também identificou-se um problema que poderia permitir a realização de um ataque de negação de serviço (DoS, na sigla em inglês) que, se implementado com sucesso, desligaria uma série de computadores, conhecidos como “nós da rede”, que trabalham na verificação da legitimidade das transações que ocorrem no sistema do Bitcoin.
Para se ter ideia da gravidade, algumas pessoas simularam a realização do ataque em uma rede de testes e conseguiram efetivamente inflacionar a emissão do Bitcoin.
Caso você tenha interesse em entender com profundidade técnica o que ocorreu no protocolo, o desenvolvedor Jimmy Song escreveu um brilhante artigo sobre o caso (disponível apenas em inglês).
Por que você deveria se preocupar
A parte mais assustadora de toda essa história é que essas vulnerabilidades habitavam o código do Bitcoin há mais de 18 meses, ou seja, em todo esse tempo ninguém percebeu a existência desses problemas. Como eu não entendo nada do código-fonte do Bitcoin, resolvi perguntar ao Algorista qual era a opinião dele em relação a tudo isso e se este caso deveria soar como um alarme para aqueles que deixam boa parte do seu capital alocado em Bitcoin.
A primeira coisa que ele me disse é que esse episódio tem “cheiro de bug door”. Segundo ele, um bug door é basicamente um pedaço de código que parece perfeito para todos, mas que sorrateiramente deixa aberta uma porta, disfarçada como um simples bug, para que um atacante possa, no futuro, explorar alguma vulnerabilidade. “O trabalho de hackeamento de sistemas é um trabalho lento, de longo prazo. Quando feito em alto nível, ele envolve injetar um bug door na base do sistema que passe despercebido. Esse problema que houve no Bitcoin tem cheiro de bug door, mas não quer dizer que tenha sido. Na verdade, ele parece mesmo uma verdadeira ‘patetada’. Eu diria que as chances de ter sido um bug door são de 40% e 60% de ter sido uma ‘patetada’. Parece uma falha não-intencional, mas que dava um acesso poderoso ao sistema”, explicou.
A parte aliviante da história, segundo Hamilton, é que este ataque apenas teria obtido êxito se todos os nós da rede do Bitcoin estivessem utilizando algum software entre as versões 14.0 e 16.2 do Bitcoin Core. Caso contrário, o atacante não conseguiria passar despercebido. “Os mineradores usam versões customizadas do software, então isso também seria um fator que diminuiria as chances de sucesso do hacker, mas ele sem dúvida poderia causar um grande tumulto na comunidade se tentasse o ataque”, disse o Algorista.
O fato do código que apresentava problema ter sido escrito por um desenvolvedor bastante conhecido do Bitcoin Core me fez perguntar ao Hamilton se a culpa havia sido do autor ou dos outros programadores que não revisaram o código direito. “Tenho 100% de convicção que foi negligência. Foram feitas três alterações que mexiam nas regras de consenso do protocolo, que é a essência do Bitcoin. Isso deveria ter passado por muito escrutínio. Pelo menos 30 pessoas independentes deveriam ter revisado o código, mas acabou sendo uma coisa decidida entre três pessoas. Mas, de certa forma, a culpa é de todo mundo, de toda a comunidade. A falta de participação no processo de desenvolvimento do código pode abrir o caminho para implementação de bug doors”, opinou.
O Bitcoin é um protocolo de código aberto e, por isso, difere completamente do trabalho de desenvolvimento de código proprietário que ocorre em uma empresa privada, por exemplo, cuja estrutura e responsabilidades são bem definidas. “Todo mundo está tratando o Bitcoin como se fosse uma estrutura empresarial, mas o desenvolvimento do código é feito por um time muito pequeno. Principalmente depois dos hard forks e das altcoins, a capacidade técnica desse time diminuiu bastante. O Bitcoin perdeu muito desenvolvedor para essas altcoins que surgiram. Hoje, os melhores desenvolvedores não estão no Bitcoin Core, estão espalhados nas altcoins. Esse tipo de problema no código também acontece nas grandes empresas, como a Apple, a Microsoft etc, mas essas empresas têm estrutura diferentes para mitigar esses eventuais problemas”, disse Hamilton.
Para o Algorista, a complexidade do Bitcoin é tamanha a ponto de atualmente não existir ninguém que consiga enxergar o código fonte de ponta a ponta. “O software do Bitcoin é experimental e está sofrendo de uma coisa chamada complexidade de código, porque ele ficou absurdamente grande. Se tivesse mais gente trabalhando na complexidade, esses bugs não teriam passado de jeito nenhum”, avalia.
Outro ponto crítico quando se encontram vulnerabilidades em projetos de código aberto tem a ver com a forma como o “disclosure” do evento é feito para a comunidade. “Em uma empresa privada que trabalha com código proprietário, quando se encontra um bug, disponibiliza-se uma atualização para os usuários do software e nem sempre explica-se o porquê. Às vezes, leva muito tempo para que as causas de determinada atualização sejam reveladas. Neste episódio recente do Bitcoin, os desenvolvedores optaram por divulgar apenas uma parte do problema com o intuito de não criar tanto alvoroço entre os usuários. Primeiramente, comunicaram sobre a existência do problema de Negação de Serviço e pediram para que a comunidade atualizasse o software para a versão 16.3 e 17.0. Mas nestas atualizações também existiam os remendos de código necessários para consertar o problema que envolvia a possibilidade de inflacionar a emissão de unidades de bitcoin”, explicou Hamilton.
Perguntei, então, se poderia haver outros bugs no código do Bitcoin. Hamilton foi enfático ao dizer que é impossível saber. “A única forma de ter essa certeza é pegar o código de ponta e ponta e revisá-lo. Com certeza, esse caso vai incentivar as pessoas a procurarem por outros bugs no código. As pessoas que têm milhões de dólares em Bitcoin deveriam pagar os desenvolvedores para revisar o código. Hoje, o incentivo para os programadores trabalharem no software principal do Bitcoin decorre apenas de empresas como a Blockstream. Esse é o ônus de um software de código aberto”, explicou.
Barão
