Análise da vulnerabilidade de estouro de inteiro no módulo de segurança de referências da linguagem Move

Recentemente, ao investigar a Aptos Moveevm, descobrimos uma nova vulnerabilidade de estouro de inteiro. O processo de ativação dessa vulnerabilidade é bastante interessante, e abaixo iremos analisar essa vulnerabilidade em profundidade e aproveitar a oportunidade para explorar alguns conceitos centrais da linguagem Move.

A linguagem Move realiza a validação de unidades de código antes de executar o bytecode, e esse processo é dividido em quatro etapas. A vulnerabilidade discutida neste artigo ocorre na etapa de reference_safety.

O módulo reference_safety é responsável principalmente por verificar a segurança das referências no código, incluindo a verificação da existência de referências pendentes, se o acesso a referências mutáveis é seguro, e se o acesso a referências de armazenamento global está em conformidade.

No processo de verificação de segurança de citações, o sistema analisará 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 sequências de instruções de ramificação e de loop.

A linguagem Move suporta dois tipos de referência: 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 melhorar a segurança e a legibilidade do código.

O principal processo de verificação de segurança de referências inclui: escanear os blocos básicos na função, analisar as instruções de bytecode 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 locais, garantindo coletivamente a segurança de referências na função.

Durante o processo de verificação, o estado antes e depois da execução do bloco básico (pre state e post state) será comparado e os resultados serão combinados para atualizar o estado do bloco. Se o estado mudar e o bloco atual tiver uma aresta de retrocesso que aponta para si mesmo (indicando que existe um ciclo), o bloco básico será executado novamente até que o estado não mude mais ou ocorra um erro.

A falha ocorre no processo de verificação se o resultado do join mudou. Quando a soma do comprimento dos parâmetros da função e do comprimento da variável local excede 256, devido ao uso do tipo u8 para representar o índice local, pode ocorrer um estouro de inteiro. Embora a linguagem Move tenha um processo para verificar o número de locals, apenas verifica a quantidade de variáveis locais, sem incluir o comprimento dos parâmetros.

Esta vulnerabilidade de estouro de inteiro pode levar a um ataque de negação de serviço ( DoS ). Um atacante pode construir um bloco de código em loop, utilizando o estouro para alterar o estado do bloco, fazendo com que o novo mapa de locais seja diferente do anterior. Quando a função execute_block for executada novamente, se o índice que a instrução precisa acessar não existir no novo mapa de locais do AbstractState, isso causará um panic, fazendo com que todo o nó trave.

Para demonstrar esta vulnerabilidade, fornecemos um PoC que pode ser reproduzido no git. Este PoC contém um bloco básico com uma instrução de branch incondicional, que pode acionar várias vezes as funções execute_block e join. Ao configurar cuidadosamente os parâmetros e o número de variáveis locais, é possível reduzir o comprimento do novo mapa de locais para 8, e então acionar um panic na segunda execução.

Esta vulnerabilidade prova novamente que não existe código absolutamente seguro. Embora a linguagem Move tenha realizado uma verificação estática rigorosa antes da execução, ainda pode ser contornada por uma vulnerabilidade de estouro. Isso também destaca a importância da auditoria de código e a necessidade de incluir verificações de segurança em tempo de execução no design da linguagem.

Como líderes na pesquisa de segurança da linguagem Move, continuaremos a investigar as questões de segurança do Move e sugerir aos designers da linguagem que adicionem mais códigos de verificação durante a execução do Move, para evitar situações imprevistas. Atualmente, a linguagem Move realiza verificações de segurança principalmente na fase de verificação, mas acreditamos que isso não é suficiente. Uma vez que a verificação seja contornada, a falta de um endurecimento de segurança adequado na fase de execução pode levar a problemas mais graves.