Post Mortem: Bug no Programa ZK ElGamal Proof

Linha do Tempo

Em abril de 2025, o pesquisador de segurança LonelySloth relatou de forma responsável uma possível vulnerabilidade ao Anza Github Security Advisory, apresentando também uma prova de conceito. Embora não tenha havido exploração identificada, a descoberta levou à ação imediata das equipes de engenharia da Anza, Firedancer e Jito, que confirmaram que a falha permitia a construção de provas arbitrárias que seriam erroneamente aceitas como válidas pelo programa ZK ElGamal Proof.

Uma atualização corretiva foi rapidamente desenvolvida e validada por referências do setor em segurança, como Asymmetric Research, Neodyme e OtterSec. Nos dias seguintes, as equipes da Solana Foundation e da Jito entraram em contato direto com operadores de validadores para distribuir o patch. Durante a distribuição, engenheiros identificaram uma segunda vulnerabilidade relacionada em outra parte do código, exigindo um patch adicional que passou pela mesma revisão rigorosa antes de ser disponibilizado.

Em cerca de 48 horas, as métricas apontaram que a supermaioria do stake já havia implementado as correções. A vulnerabilidade foi posteriormente comunicada publicamente pelo Discord. O cluster Solana já adotou as correções, e não há fundos em risco.

Preliminares

As transferências confidenciais do Token-2022 funcionam por meio da integração entre dois programas: Token-2022 e ZK ElGamal Proof. O Token-2022 atua como principal componente on-chain para gestão de emissões, contas e lógica central dos tokens. O programa ZK ElGamal Proof, por sua vez, é nativo e dedicado à validação matemática de zero-knowledge proofs complexas que atestam a validade dos saldos criptografados em contas e transações.

Os sistemas de zero-knowledge proof geralmente transformam protocolos interativos de duas partes em provas não interativas via Fiat-Shamir Transformation, técnica fundamental em criptografia. Essa transformação permite a geração determinística de aleatoriedade pública por meio de funções hash criptográficas. Na validação de provas geradas pela Fiat-Shamir Transformation, todos os componentes algébricos da estrutura da prova precisam ser totalmente hasheados, garantindo integridade e não-repúdio do processo de verificação.

O Bug

A falha estava no programa on-chain ZK ElGamal Proof, onde certos componentes algébricos essenciais foram deixados de fora da função hash usada para gerar o transcript criptográfico requerido pela Fiat-Shamir Transformation. Essa lacuna permitia a um atacante sofisticado manipular esses componentes não hasheados para criar uma prova forjada que passaria pelos mecanismos de verificação, sendo incorretamente aceita como válida.

O impacto foi restrito aos tokens confidenciais Token-2022, mas dentro desse escopo era severo: atacantes poderiam realizar operações não autorizadas, como emitir tokens ilimitados ou sacar de contas arbitrárias, sem autorização. Por exigir conhecimento técnico avançado, a vulnerabilidade era de severidade crítica, demandando correção imediata.

A Correção

O programa ZK ElGamal Proof foi totalmente corrigido para incluir todos os componentes algébricos omitidos na função hash da Fiat-Shamir Transformation. As versões corrigidas estão disponíveis nas principais implementações Solana:

• Agave: versão 2.1.21 ou superior, e versão 2.2.11 ou superior
• Jito-Solana: versão 2.1.21-jito ou superior, e versão 2.2.11-jito ou superior
• Firedancer: versão 0.411.20121 ou superior

O patch passou por revisão de segurança independente junto à Asymmetric Research, Neodyme e OtterSec. O programa ZK ElGamal Proof já havia sido auditado extensivamente. Como a vulnerabilidade estava restrita a esse programa, não foram necessárias mudanças no Token-2022. Todos os fundos seguem seguros, e não há registro de exploração dessa falha na rede Solana.

Conclusão

Este post mortem evidencia a eficácia do reporte responsável de vulnerabilidades e da resposta ágil a incidentes na proteção de infraestruturas blockchain. O reporte técnico de LonelySloth permitiu colaboração imediata entre equipes de desenvolvimento e empresas de segurança para identificar, corrigir e implantar a solução crítica em cerca de 48 horas. Embora a vulnerabilidade fosse teoricamente grave, a resposta coordenada impediu danos práticos. O sucesso na distribuição dos patches à rede de validadores comprova a maturidade e agilidade da segurança do Solana, mantendo as transferências confidenciais Token-2022 seguras e confiáveis para toda a comunidade.

FAQ

Quais são os principais motivos para realizar um post mortem?

Post mortems identificam causas-raiz de falhas, evitam reincidências, fortalecem a confiabilidade do sistema, aprimoram protocolos de segurança e documentam aprendizados para evolução e transparência organizacional.