Foi descoberto uma nova vulnerabilidade de estouro de inteiro no módulo de segurança da linguagem Move.

Recentemente, durante uma pesquisa aprofundada na linguagem Move, descobrimos uma nova vulnerabilidade de estouro de inteiro. Esta vulnerabilidade existe no processo de verificação de segurança de referências, e seu processo de ativação é bastante interessante. Este artigo irá analisar a fundo essa vulnerabilidade e explorar alguns conhecimentos de fundo sobre a linguagem Move.

A linguagem Move realiza a validação da unidade de código antes de executar o bytecode, dividindo-se em quatro etapas. Esta vulnerabilidade ocorre na etapa reference_safety. Esta etapa é responsável por validar a segurança das referências, incluindo verificar se existem referências pendentes, se o acesso a referências mutáveis é seguro, e se o acesso a referências de armazenamento global é seguro, entre outros.

A função de entrada que invoca a verificação de segurança chamará analyze_function, que valida cada bloco básico. Um bloco básico refere-se a uma sequência de código que não possui instruções de ramificação, exceto a entrada e a saída. A linguagem Move identifica blocos básicos percorrendo o bytecode e procurando todas as instruções de ramificação e sequências de instruções de loop.

A linguagem Move suporta dois tipos de referências: referências imutáveis (&) e referências mutáveis (&mut). O módulo de segurança de referências valida a legalidade de todas as operações de referência através da análise das instruções de bytecode nos blocos básicos das funções. O processo de validação utiliza a estrutura AbstractState, que contém o gráfico de empréstimos e os locais, para garantir a segurança das referências dentro da função.

A vulnerabilidade ocorre na função join_. Quando o comprimento dos parâmetros mais o comprimento das variáveis locais excede 256, devido à função iter_locals() retornar um iterador do tipo u8, isso pode causar um estouro de inteiro. Embora o Move tenha um processo de verificação do número de locals, no módulo check bounds, apenas verifica os locals, sem incluir o comprimento dos parâmetros.

Essa sobrecarga de inteiro pode levar a um ataque de negação de serviço (DoS). Quando há um bloco de código em loop e a sobrecarga altera o estado do bloco, o novo mapa de locais é diferente do anterior. Ao executar novamente a função execute_block, se o índice que a instrução precisa acessar não existir no novo mapa de locais do AbstractState, isso causará um DoS.

Fornecemos um PoC que pode ser reproduzido no git. O bloco de código neste PoC contém uma instrução de desvio incondicional que, a cada execução da última instrução, salta de volta para a primeira instrução, chamando repetidamente as funções execute_block e join.

Esta vulnerabilidade demonstra que mesmo linguagens que priorizam a segurança, como Move, podem ter riscos de segurança. A importância da auditoria de código é inegável, e os programadores não estão imunes a descuidos. Como líderes na pesquisa de segurança da linguagem Move, continuaremos a investigar profundamente os problemas de segurança do Move.

Recomendamos que os designers da linguagem Move adicionem mais código de verificação em tempo de execução para evitar situações inesperadas. Atualmente, a Move realiza verificações de segurança principalmente na fase de verificação, mas isso pode não ser suficiente. Uma vez que a validação é contornada, a falta de reforço de segurança suficiente na fase de execução pode levar a problemas mais graves.