Análise da vulnerabilidade de estouro de inteiros na verificação de segurança de referências em Move

Recentemente, pesquisadores descobriram uma nova vulnerabilidade de estouro de inteiro ao analisar profundamente o Aptos Moveevm. Esta vulnerabilidade existe no processo de verificação de segurança de referências da linguagem Move, especificamente no passo reference_safety. Este artigo irá explorar profundamente essa vulnerabilidade e explicar seu processo de ativação e seus potenciais impactos.

Processo de validação da linguagem Move

A linguagem Move realiza a validação da unidade de código antes de executar o bytecode, e esse processo é dividido em 4 etapas. A vulnerabilidade descoberta desta vez ocorreu na etapa de reference_safety. Esta etapa é principalmente usada para validar a segurança das referências, incluindo a verificação da existência de referências pendentes, se o acesso a referências mutáveis é seguro, se o acesso a referências de armazenamento global é seguro, entre outros.

O processo de verificação começa por identificar blocos básicos. Na linguagem Move, os blocos básicos são determinados percorrendo o bytecode e procurando todas as sequências de instruções de ramificação e de loop. Cada bloco básico é uma sequência de código que não possui instruções de ramificação, exceto a entrada e a saída.

Mecanismo de verificação de segurança de citações

A linguagem Move suporta dois tipos de referências: referências imutáveis (&) e referências mutáveis (&mut). O módulo de verificação de segurança de referências irá escanear as instruções de bytecode de cada bloco básico da função, determinando se todas as operações de referência são válidas.

O processo de verificação utiliza a estrutura AbstractState para representar o estado, que contém dois componentes-chave: o grafo de empréstimos e os locais. Durante a verificação, serão comparadas as mudanças de estado antes e depois da execução do bloco básico, e os resultados serão propagados para os blocos subsequentes.

Detalhes da vulnerabilidade

A vulnerabilidade existe na função join_. Esta função é usada para mesclar o estado antes e depois da execução de blocos básicos. O problema está no método iter_locals(), que retorna um iterador do tipo u8. Quando a soma do comprimento dos parâmetros da função e do comprimento das variáveis locais excede 256, isso leva a um estouro de inteiro.

Embora a linguagem Move tenha um processo de verificação do número de locais, ela apenas verifica a quantidade de variáveis locais, sem incluir o comprimento dos parâmetros. Isso pode ser uma negligência dos desenvolvedores.

Exploração de Vulnerabilidades e Impactos

Usando essa vulnerabilidade de estouro de inteiro, um atacante pode construir blocos de código de loop especiais para alterar o estado do bloco. Quando o bloco básico é executado novamente, se o índice acessado pela instrução não existir no novo mapa de locais, isso resultará em uma negação de serviço (DoS).

Especificamente, no módulo de segurança de referência, os códigos de operação MoveLoc/CopyLoc/FreeRef podem causar pânico devido ao acesso a um LocalIndex inexistente, levando à falha de todo o nó.

Resumo e Sugestões

Esta vulnerabilidade prova mais uma vez que mesmo linguagens cuidadosamente projetadas podem ter falhas de segurança. Para a linguagem Move, recomendamos:

1. Reforçar a auditoria de código para evitar descuidos semelhantes.
2. Adicionar mais código de verificação na execução do Move, não dependendo apenas das verificações de segurança na fase de validação.
3. Adicionar medidas de segurança na fase de operação para evitar problemas mais graves após a validação ser contornada.

Como pioneiros na pesquisa de segurança da linguagem Move, continuaremos a explorar profundamente as questões de segurança relacionadas, contribuindo para o desenvolvimento saudável do ecossistema Move.