“Falha de dez anos” do XRP viraliza: a correção já foi aplicada; o que realmente importa são estas três diferenças de tempo
“Gerar XRP do nada” soa como um incidente em andamento. Vamos acertar o relógio: a divulgação pública da vulnerabilidade ocorreu em 9 de outubro; a correção do mecanismo de pagamentos já havia sido lançada com o xrpld 3.4.1. Em 10 de outubro, o GitHub também publicou o código-fonte dessa versão e as instruções de atualização. Divulgação, correção do software e ativação das regras na mainnet respondem a perguntas diferentes.
Primeiro, a vulnerabilidade do mecanismo de pagamentos afeta a versão 3.4.0 e anteriores. Em 22 de setembro, pesquisadores a relataram por meio do programa de recompensas por bugs. Depois de reproduzir o problema, a equipe elevou sua gravidade e lançou uma correção em 25 de setembro. A investigação oficial estima que o problema possa remontar a um código de 2015. O relatório afirma que não foram encontradas evidências de exploração na rede pública. Essa é uma conclusão da investigação; não se pode extrapolá-la para afirmar que todas as atividades históricas foram comprovadamente normais, muito menos dizer diretamente que houve um ataque de emissão indevida de tokens.
Segundo, o mesmo relatório também inclui um problema na validação de transações internas do Batch. Quando essa regra foi identificada, ela ainda não estava ativada na mainnet. O software já incluía a correção, mas o fixBatchV1_2 só foi ativado na mainnet em 9 de outubro; a correção do mecanismo de pagamentos entrou em vigor imediatamente, com a atualização dos nós. Misturar os dois caminhos de correção e dizer que “todas as vulnerabilidades só foram bloqueadas em 9 de outubro” representa incorretamente o período de exposição ao risco.
Terceiro, as considerações de quem simplesmente mantém XRP e de quem opera um nó não devem ser confundidas. O GitHub exige atualmente que os servidores sejam atualizados para a versão 3.4.1 e informa que as versões antigas foram bloqueadas por uma nova emenda e não conseguem mais sincronizar normalmente. Essa exigência de atualização se aplica ao software do servidor; não significa que quem mantém XRP precise transferir seus ativos para um site desconhecido para “consertar a carteira”. Se receber um link que, em nome da segurança, peça a frase-semente ou uma autorização, confira primeiro se ele é de um canal oficial.
O que tiro deste incidente é que as defesas de segurança não devem se apoiar repetidamente na mesma hipótese: se há um problema no cálculo de pagamentos, a camada de verificação também pode deixar de detectá-lo caso use a mesma suposição aritmética. Por isso, vale acompanhar tanto a correção quanto o processo de revisão posterior. Essa inferência decorre do mecanismo de divulgação e não equivale a uma conclusão sobre vulnerabilidades em outros protocolos.
Vou continuar acompanhando se as fontes oficiais acrescentam resultados à investigação, o progresso das atualizações dos nós antigos e as revisões de segurança posteriores. Esses fatores podem mudar a avaliação do risco técnico; já uma alta sustentada do preço exige evidências de volume negociado e de demanda compradora. A correção de uma vulnerabilidade de segurança, por si só, não permite concluir que seja um sinal de compra.
Fontes: divulgação oficial da vulnerabilidade pela XRPL em 9 de outubro; notas de lançamento da versão 3.4.1 do XRPLF/rippled. Verificado em 10 de outubro, às 22h36, horário de Pequim.
“Gerar XRP do nada” soa como um incidente em andamento. Vamos acertar o relógio: a divulgação pública da vulnerabilidade ocorreu em 9 de outubro; a correção do mecanismo de pagamentos já havia sido lançada com o xrpld 3.4.1. Em 10 de outubro, o GitHub também publicou o código-fonte dessa versão e as instruções de atualização. Divulgação, correção do software e ativação das regras na mainnet respondem a perguntas diferentes.
Primeiro, a vulnerabilidade do mecanismo de pagamentos afeta a versão 3.4.0 e anteriores. Em 22 de setembro, pesquisadores a relataram por meio do programa de recompensas por bugs. Depois de reproduzir o problema, a equipe elevou sua gravidade e lançou uma correção em 25 de setembro. A investigação oficial estima que o problema possa remontar a um código de 2015. O relatório afirma que não foram encontradas evidências de exploração na rede pública. Essa é uma conclusão da investigação; não se pode extrapolá-la para afirmar que todas as atividades históricas foram comprovadamente normais, muito menos dizer diretamente que houve um ataque de emissão indevida de tokens.
Segundo, o mesmo relatório também inclui um problema na validação de transações internas do Batch. Quando essa regra foi identificada, ela ainda não estava ativada na mainnet. O software já incluía a correção, mas o fixBatchV1_2 só foi ativado na mainnet em 9 de outubro; a correção do mecanismo de pagamentos entrou em vigor imediatamente, com a atualização dos nós. Misturar os dois caminhos de correção e dizer que “todas as vulnerabilidades só foram bloqueadas em 9 de outubro” representa incorretamente o período de exposição ao risco.
Terceiro, as considerações de quem simplesmente mantém XRP e de quem opera um nó não devem ser confundidas. O GitHub exige atualmente que os servidores sejam atualizados para a versão 3.4.1 e informa que as versões antigas foram bloqueadas por uma nova emenda e não conseguem mais sincronizar normalmente. Essa exigência de atualização se aplica ao software do servidor; não significa que quem mantém XRP precise transferir seus ativos para um site desconhecido para “consertar a carteira”. Se receber um link que, em nome da segurança, peça a frase-semente ou uma autorização, confira primeiro se ele é de um canal oficial.
O que tiro deste incidente é que as defesas de segurança não devem se apoiar repetidamente na mesma hipótese: se há um problema no cálculo de pagamentos, a camada de verificação também pode deixar de detectá-lo caso use a mesma suposição aritmética. Por isso, vale acompanhar tanto a correção quanto o processo de revisão posterior. Essa inferência decorre do mecanismo de divulgação e não equivale a uma conclusão sobre vulnerabilidades em outros protocolos.
Vou continuar acompanhando se as fontes oficiais acrescentam resultados à investigação, o progresso das atualizações dos nós antigos e as revisões de segurança posteriores. Esses fatores podem mudar a avaliação do risco técnico; já uma alta sustentada do preço exige evidências de volume negociado e de demanda compradora. A correção de uma vulnerabilidade de segurança, por si só, não permite concluir que seja um sinal de compra.
Fontes: divulgação oficial da vulnerabilidade pela XRPL em 9 de outubro; notas de lançamento da versão 3.4.1 do XRPLF/rippled. Verificado em 10 de outubro, às 22h36, horário de Pequim.