Análise Profunda da Vulnerabilidade de Segurança em Referências da Linguagem Move

Recentemente, ao realizarmos uma pesquisa aprofundada sobre o Aptos Moveevm, descobrimos uma nova vulnerabilidade de estouro de inteiro. O processo de ativação dessa vulnerabilidade é bastante interessante, a seguir faremos uma análise aprofundada e apresentaremos conhecimentos de fundo relacionados à linguagem Move. Através da explicação deste artigo, acreditamos que os leitores poderão ter uma compreensão mais profunda 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 discutida neste artigo ocorre na etapa de reference_safety.

O módulo reference_safety define a função de transferência utilizada para verificar a segurança da referência dos sujeitos do processo. Ele verifica principalmente se existem referências pendentes, se o acesso a referências mutáveis é seguro, se o acesso a referências de armazenamento global é seguro, entre outros problemas.

O processo de verificação começa com a função de entrada de verificação de segurança, que chamará a analyze_function. Na analyze_function, cada bloco básico será verificado. Um bloco básico é uma sequência de código que não possui instruções de ramificação, exceto nas entradas e saídas.

A linguagem Move identifica blocos básicos percorrendo o bytecode, procurando todas as sequências de instruções de ramificação e 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.

A linguagem Move suporta dois tipos de referências: referência imutável (&) e referência mutável (&mut). A referência imutável é usada para ler dados, enquanto a referência mutável é usada para modificar dados. Este design ajuda a manter a segurança do código e a identificar módulos de leitura.

O principal processo de verificação de segurança de referências inclui: escanear as instruções de bytecode dos blocos básicos na função e determinar se todas as operações de referência são legais. Este processo utiliza a estrutura AbstractState, que contém o grafo de empréstimos e as variáveis locais, para garantir a segurança das referências na função.

Durante o processo de validação, o código do bloco básico será executado, gerando o estado pós (post state), que será então combinado com o estado pré (pre state) para atualizar o estado do bloco, e as condições posteriores desse bloco serão propagadas para os blocos subsequentes. Este processo é semelhante à ideia do Sea of Nodes no V8 turbofan.

A vulnerabilidade ocorre na função join_. Quando a soma do comprimento dos parâmetros e do comprimento das variáveis locais é superior a 256, devido ao tipo local ser u8, ocorre um estouro de inteiro. Embora o Move tenha um processo de verificação do número de locals, no módulo de verificação de limites, apenas os locals foram verificados, não incluindo o comprimento dos parâmetros.

Esta vulnerabilidade de estouro de inteiro pode levar a um ataque DoS. Ao criar um bloco de código em loop e explorar o estouro para alterar o estado do bloco, o novo mapa de locais pode ser diferente do anterior. Quando a função execute_block é executada novamente, se o índice que a instrução precisa acessar não existir no novo mapa de locais do AbstractState, isso pode causar um DoS.

Descobrimos que, no módulo de referência de segurança, os códigos de operação MoveLoc/CopyLoc/FreeRef podem alcançar esse objetivo. Tomando a função copy_loc como exemplo, se o LocalIndex não existir, isso resultará em panic, fazendo com que todo o nó falhe.

Para validar esta vulnerabilidade, escrevemos um PoC. O bloco de código neste PoC contém uma instrução de desvio incondicional que, sempre que a última instrução é executada, salta de volta para a primeira instrução, portanto, este bloco de código chamará várias vezes as funções execute_block e join.

Ao definir os parâmetros adequados, podemos fazer com que o novo comprimento do mapa locals se torne 8. Na segunda execução da função execute_block, devido ao comprimento insuficiente de locals, isso resultará em um panic.

Esta vulnerabilidade nos lembra que até mesmo linguagens que enfatizam a segurança, como o Move, podem ter falhas. Recomendamos que os designers da linguagem Move adicionem mais códigos de verificação em tempo de execução para evitar situações inesperadas. Atualmente, a linguagem Move realiza verificações de segurança principalmente na fase de verificação, mas isso pode não ser suficiente. Se a validação for contornada e não houver reforço de segurança suficiente na fase de execução, isso pode levar a problemas mais graves.

Como líder em pesquisa de segurança da linguagem Move, continuaremos a investigar profundamente os problemas de segurança do Move e compartilharemos mais descobertas no futuro.