Bem-vindo de volta ao Destaque de Vulnerabilidade do Sherlock, onde destacamos uma vulnerabilidade impactante descoberta durante uma auditoria do Sherlock. Esta semana, examinamos uma negação de serviço encontrada no concurso de @GMX_IO por @0xdeadbeef____ e @IllIllI000. Crédito para @int0x1catedCode pelo colapso.
Resumo da vulnerabilidade: A vulnerabilidade permite que um invasor manipule o fluxo de execução de ordens, fornecendo comprimentos de motivo de reversão falsos que não correspondem aos dados reais. Isso faz com que o tratamento de erros do protocolo leia regiões de memória incorretas, potencialmente interrompendo o processo de execução ou causando um comportamento inesperado ao processar pedidos com falha.
Etapas de ataque: 1. Fase de configuração Implantar um contrato mal-intencionado que implementa o comportamento de reversão personalizado O contrato malicioso deve ser invocado pelo protocolo de destino (por exemplo, como manipulador de retorno de chamada). 2. Crie dados de reversão maliciosos Estrutura reverte dados com um parâmetro de comprimento falsificado. 3. Execute a ordem por meio do protocolo Crie um pedido que acionará a interação com o contrato malicioso Quando o protocolo processa o pedido e chama o contrato malicioso, ele reverte com os dados criados. O tratamento de erros do protocolo tenta decodificar o motivo da reversão usando o comprimento falso. 4. Acione o estouro de leitura de memória O protocolo lê a memória com base no parâmetro de comprimento falso Isso faz com que ele leia além dos limites reais dos dados de reversão.
Qual é o impacto? Negação de serviço: as ordens podem não ser executadas corretamente, bloqueando operações legítimas de protocolo, como liquidação de posições incorretas Interrupção da execução da ordem: o processamento da ordem em lote pode ser interrompido, afetando vários usuários Griefing de gás: o processamento de dados de reversão malformados pode consumir gás excessivo
A causa raiz: 1. Parâmetros de comprimento não verificados: O protocolo confia no valor de comprimento fornecido nos dados de reversão sem validação 2. Verificações de limite ausentes: nenhuma verificação de que o comprimento reivindicado corresponde ao tamanho real dos dados
A mitigação: 1. Sempre valide o comprimento dos dados de reversão 2. Implemente limites máximos de comprimento
Estamos orgulhosos de ter ajudado a garantir @GMX_IO por meio dessa descoberta. Quando absolutamente precisa ser seguro, Sherlock é a escolha certa.
2,32K