Análise Profunda de outra vulnerabilidade crítica na linguagem Move

Anteriormente, descobrimos uma grave vulnerabilidade no Aptos Moveevm, e após uma pesquisa aprofundada, encontramos uma nova vulnerabilidade de estouro de inteiro. O processo de ativação desta vulnerabilidade é ainda mais interessante; a seguir, vamos analisar este problema em profundidade, ao mesmo tempo que apresentamos alguns conhecimentos de fundo sobre a linguagem Move. Acreditamos que, através da explicação deste artigo, você terá uma compreensão mais profunda da linguagem Move.

É de conhecimento geral que a linguagem Move valida a unidade de código antes de executar o bytecode. O processo de validação é dividido em 4 etapas, e esta vulnerabilidade ocorre na etapa de reference_safety.

O módulo reference_safety define a função de transferência para verificar a segurança das referências do sujeito do processo. As suas verificações incluem a validação de que não há referências não resolvidas, 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. Na analyze_function, a função irá validar 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 determina blocos básicos percorrendo o bytecode, procurando todas as instruções de ramo e sequências de instruções de loop. Um exemplo típico de bloco básico de código Move IR pode conter 3 blocos básicos, determinados pelas instruções BrTrue, Branch e Ret.

Segurança de referência em Move

Inspirando-se na filosofia da linguagem Rust, Move suporta dois tipos de referências: referência imutável (&) e referência mutável (&mut). A referência imutável é utilizada para ler dados de uma estrutura, enquanto a referência mutável é utilizada para modificar dados. O uso adequado dos tipos de referência ajuda a manter a segurança e a identificar os módulos de leitura.

O módulo de segurança de referência do Move irá escanear, por unidade de função, as instruções de bytecode dos blocos básicos dentro da função, verificando se todas as operações de referência são legais. O processo de verificação envolve principalmente a estrutura AbstractState, que contém o gráfico de empréstimos e as variáveis locais, para garantir a segurança das referências dentro da função.

O processo de verificação compara o estado antes e depois da execução do bloco básico, e combina os resultados para atualizar o estado do bloco, enquanto propaga as condições pós-bloco para os blocos subsequentes. Este processo é semelhante à ideia Sea of Nodes no V8 turbofan.

O ciclo principal executará o código do bloco e tentará mesclar o estado prévio e o estado posterior. Se o estado mudar e o bloco atual tiver uma aresta de retrocesso que aponta para si mesmo ( indicando um ciclo ), ele retornará ao início do ciclo e continuará a executar este bloco básico até que o estado posterior seja igual ao estado prévio ou seja interrompido devido a um erro.

Análise de Vulnerabilidades

A vulnerabilidade ocorre no processo de verificação se o resultado do join foi alterado. A função join_ é utilizada para atualizar as variáveis locais e o gráfico de relações de empréstimo. Quando o comprimento dos parâmetros da função mais o comprimento das variáveis locais excede 256, ocorre um estouro durante a iteração sobre os locais, uma vez que as variáveis locais são do tipo u8.

Embora o Move tenha um processo para verificar o número de locals, o módulo check bounds apenas verifica os locals, não incluindo o parâmetro length. Os desenvolvedores parecem perceber que é necessário verificar a soma dos parâmetros e dos valores locais, mas o código realmente só verifica o número de variáveis locais.

De estouro de inteiro a ataque DoS

O ciclo principal irá escanear o bloco de código e chamar a função execute_block, em seguida, irá mesclar o estado anterior e posterior à execução. Quando há um ciclo no código, irá saltar para o início do bloco de código e executar novamente.

Se construirmos um bloco de código em loop e utilizarmos o overflow para alterar o estado do bloco, fazendo com que o novo mapa de locais seja diferente do anterior, ao executar novamente o execute_block, a análise da sequência de instruções no bloco básico irá acessar o novo mapa de locais. Nesse caso, se o índice que as instruções precisam acessar não existir no novo mapa, isso resultará em DoS.

No módulo reference safety, os códigos de operação MoveLoc/CopyLoc/FreeRef podem alcançar esse objetivo. Tomando como exemplo a função copy_loc, ela tentará obter o valor local através do LocalIndex; se o LocalIndex não existir, isso resultará em panic, fazendo com que todo o nó falhe.

Demonstração de PoC

Podemos construir um bloco básico que contém instruções de ramificação incondicional, fazendo chamadas múltiplas às funções execute_block e join. Ao definir os parâmetros adequados e o número de variáveis locais, é possível reduzir o comprimento do novo mapa de locais para 8 após a primeira execução.

Na segunda execução, tentar acessar um offset inexistente causará panic, resultando em um DoS.

Resumo

Esta vulnerabilidade demonstra que, mesmo a linguagem Move, que passou por uma rigorosa verificação estática, apresenta riscos de segurança. A vulnerabilidade de estouro pode contornar a verificação de limites, ressaltando a importância da auditoria de código.

Como líderes em pesquisa de segurança da linguagem Move, recomendamos que os designers da linguagem adicionem mais códigos de verificação no tempo de execução do Move, para evitar a ocorrência de situações inesperadas. Atualmente, o Move realiza verificações de segurança principalmente na fase de verificação, mas falta um reforço de segurança suficiente na fase de execução, o que pode levar a problemas mais graves.

Nós também descobrimos outra vulnerabilidade na linguagem Move, que compartilharemos com todos posteriormente.