Um dos clientes de consenso do Ethereum mesclou uma correção para um ataque de envenenamento do cache de chaves públicas de validadores, de acordo com um pull request no GitHub. O patch aborda uma vulnerabilidade em torno do fork Gloas, que poderia resultar em alguns nós rejeitando assinaturas válidas devido a um bug no cache global de chaves públicas.
Gloas é a parte da camada de consenso da próxima atualização Glamsterdam.
Três depósitos, duas cadeias
O problema está em um mecanismo no qual o cliente armazena chaves públicas de validadores e seus índices em um cache global.
Tecnicamente, depósitos que já foram finalizados deveriam produzir os mesmos validadores em todas as cadeias, embora seja uma história diferente no limite do fork.
O atacante precisa de 3 depósitos pendentes pouco antes do fork. O primeiro é uma grande recarga para um validador existente. Os outros dois são novas chaves: A com credenciais de builder e B com credenciais regulares de validador.
Na cadeia canônica, a recarga consome a rotatividade de saldo, então A e B são processados após o fork. A se torna um builder, e B assume o próximo índice de validador.
Na cadeia lateral do atacante, o validador recarregado sofre slashing antes do fork, e seu depósito é ignorado. Isso leva A a ser processado mais cedo, essencialmente assumindo o índice de B.
O cache com bug assumia que ambas as cadeias produziriam os mesmos validadores e importou a chave de A globalmente.
No fork, os nós afetados rejeitariam todas as assinaturas válidas de B na cadeia canônica e fariam fork.
Realisticamente, o ataque é um tanto complicado, pois precisa de um slashing no momento certo e de uma cadeia lateral, então é improvável que aconteça por acidente.
O que a correção muda?
De acordo com o PR, a correção é adicionar chaves ao cache global de chaves públicas apenas quando sua época de elegibilidade para ativação for finalizada.
Uma nova estrutura HeadPubkeys também combina chaves do estado head e do cache global, para que os nós não percam chaves se a cadeia finalizar sem novos blocos.
Se outros clientes de consenso tinham um problema semelhante ainda precisa ser confirmado. Em outras palavras, quanto mais perto o Glamsterdam chega, mais casos extremos em torno do limite do fork os desenvolvedores precisam capturar.
