O Diretor de Engenharia da Ripple, Vijay Khanna, pediu aos operadores de nós do XRP Ledger em 2 de agosto que instalassem a versão 3.2.1 do xrpld depois que os desenvolvedores observaram uma inundação de manifestos de validadores em 31 de julho.
Resumo
- A inundação de manifestos em 31 de julho levou ao xrpld 3.2.1, enquanto o XRP Ledger continuou fechando ledgers normalmente durante todo o evento.
- Quatro salvaguardas agora limitam o tamanho do manifesto, lotes de mensagens, compartilhamento de saída e crescimento do cache de chaves desconhecidas em toda a rede.
- Os operadores devem atualizar, verificar se o xrpld está em execução e reiniciar novamente para limpar manifestos persistidos com segurança.
O hotfix limita como os nós processam, armazenam e compartilham dados recebidos de identidades de validadores desconhecidas.
O XRP Ledger continuou fechando ledgers normalmente durante o evento, de acordo com o XRP Ledger Operations. As evidências disponíveis apontam, portanto, para pressão nos recursos dos nós e nas comunicações ponto a ponto, em vez de uma perda confirmada de fundos, transações alteradas ou falha no consenso do ledger. Os desenvolvedores não publicaram um identificador CVE ou estimativa de perda financeira relacionada ao incidente.
XRPL 3.2.1 limita a rota de inundação de manifestos
Manifestos de validadores são registros assinados criptograficamente que conectam a identidade mestre estável de um validador à chave temporária que ele usa para mensagens de validação diárias. Quando os operadores rotacionam essas chaves temporárias, eles publicam um novo manifesto assinado pela chave mestre para que outros nós possam verificar a mudança.
Antes do hotfix, os nós podiam aceitar, armazenar em cache e retransmitir manifestos com estrutura válida associados a chaves de validadores que não reconheciam. Um atacante poderia explorar esse comportamento produzindo muitas identidades desconhecidas e forçando os pares a gastar memória, armazenamento, largura de banda e capacidade de processamento para lidar com os dados. O registro público do código descreve a falha como um problema com a propagação de manifestos.
O lançamento oficial do xrpld 3.2.1 é datado de 31 de julho e foi publicado como o lançamento assinado mais recente no início de 1º de agosto. Ele contém seis commits em 13 arquivos alterados, incluindo quatro commits que restringem diretamente o manuseio de manifestos não confiáveis.
Quatro salvaguardas reduzem o risco de esgotamento de recursos
A primeira salvaguarda rejeita um manifesto de validador superdimensionado antes que o nó o decodifique completamente. Isso reduz o trabalho de processamento que um atacante pode acionar enviando objetos individuais maiores do que o software espera.
A segunda limita o número de manifestos não confiáveis transportados em uma única mensagem de rede. O limite se aplica quando os nós recebem os dados e quando preparam mensagens de manifesto para os pares. Lotes superdimensionados são descartados sem desconectar automaticamente um par não corrigido, o que ajuda nós atualizados e mais antigos a permanecerem conectados durante a implementação.
Uma terceira mudança limita o número de identidades de validadores desconhecidas mantidas no cache de manifestos de um nó. O código final define o máximo em 100. Quando essa capacidade é atingida, o software rejeita manifestos vinculados a novas chaves não listadas, enquanto continua processando validadores confiáveis ou previamente reconhecidos.
O patch também altera como as informações de manifestos não confiáveis são retidas e propagadas. Os dados de validadores confiáveis permanecem disponíveis porque as restrições visam fofocas de pares não listados, em vez de manifestos de validadores configurados ou aprovados. Essa distinção permite que a rotação normal de chaves de validadores continue, bloqueando o crescimento descontrolado do cache.
Operadores de nós devem concluir uma segunda reinicialização
Khanna aconselhou validadores e outros operadores de infraestrutura a atualizar para a versão 3.2.1 "o mais rápido possível". Suas instruções pedem uma atualização normal de software, seguida de uma espera de um a dois minutos e uma verificação de que o xrpld está em execução. Os operadores devem então reiniciar o serviço novamente.
A segunda reinicialização é importante para nós que podem ter retido manifestos desconhecidos antes de instalar a correção. A atualização muda o tratamento futuro, enquanto reiniciar o servidor corrigido ajuda a garantir que dados antigos na memória ou retidos anteriormente não continuem afetando as operações.
Os operadores também podem precisar confirmar que seus sistemas confiam na chave de assinatura de pacotes atual da Ripple. As notas de versão afirmam que a Ripple rotacionou a chave GPG usada para assinar pacotes xrpld em 18 de fevereiro. Instalações existentes que não confiaram na chave substituta podem não receber atualizações automáticas com sucesso.
A atualização se aplica a provedores de infraestrutura, não a detentores comuns de XRP. Os usuários não precisam mover XRP, alterar chaves de carteira ou criar novas contas por causa do problema de manifestos. Exchanges, custodiantes, backends de carteiras, provedores de dados e empresas que executam seus próprios servidores XRPL devem, em vez disso, confirmar suas versões de nó e status de reinicialização.
O post-mortem determinará o escopo do incidente
A XRP Ledger Operations disse que um "post-mortem técnico seguirá em breve". Em 2 de agosto, o projeto não havia publicado esse relatório, então a identidade do remetente, o volume de manifestos transmitidos e o uso exato de recursos nos nós afetados permanecem não divulgados.
O relatório também deve esclarecer quando os desenvolvedores detectaram a atividade pela primeira vez, se algum nó ficou indisponível e com que rapidez os operadores adotaram a versão 3.2.1. Embora os ledgers continuassem fechando, a adoção lenta de patches pode deixar servidores individuais expostos a inundações renovadas, mesmo quando o ledger compartilhado permanece operacional.
O hotfix chega logo após o lançamento da versão maior 3.2.0 do XRPL. Esse lançamento, emitido em 15 de junho, renomeou o servidor de referência de rippled para xrpld e introduziu mudanças de infraestrutura que exigiram que os operadores atualizassem software e configurações de serviço.
Como relatado anteriormente, a versão 3.2.0 inicialmente se espalhou mais rápido entre validadores do que na rede de nós mais ampla. A inundação de manifestos adiciona uma nova razão para os operadores restantes irem além desse lançamento e instalarem o hotfix.
Enquanto isso, em cobertura relacionada, David Schwartz moveu sua infraestrutura XRPL para a versão 3.2.0 enquanto os desenvolvedores preparavam a rede para a nova nomenclatura de servidor e recursos de protocolo. Anteriormente, como crypto.news relatou, os operadores de nós também enfrentaram um prazo da versão 3.1.3 ligado à ativação de uma emenda.
As próximas atualizações verificadas serão o post-mortem prometido e novos dados de adoção de software. Até então, a resposta confirmada permanece limitada ao lançamento 3.2.1, seus quatro controles de manifestos e o pedido para que os operadores concluam o processo de atualização e reinicialização.
