Análise de vulnerabilidades de estouro de inteiro na linguagem Move
Introdução
Após uma pesquisa aprofundada sobre o Aptos Moveevm, descobrimos uma nova vulnerabilidade de estouro de inteiro. O processo de ativação dessa vulnerabilidade é relativamente mais interessante, a seguir faremos uma análise aprofundada dessa vulnerabilidade e apresentaremos algumas informações de fundo sobre a linguagem Move. Através da explicação deste artigo, acreditamos que você terá uma compreensão mais profunda da linguagem Move.
A linguagem Move valida as unidades de código antes de executar o bytecode. O processo de validação é dividido em 4 etapas, e essa vulnerabilidade ocorre na etapa de reference_safety.
Segurança de referência em Move
A linguagem Move suporta dois tipos de referências: referências imutáveis (&) e referências mutáveis (&mut). As referências imutáveis são usadas para ler dados de uma estrutura, enquanto as referências mutáveis são usadas para modificar dados. Usar o tipo de referência apropriado ajuda a manter a segurança e a identificar os módulos de leitura.
No módulo de segurança de referência do Move, as instruções de bytecode dos blocos básicos dentro das funções são analisadas para verificar se todas as operações de referência são legais. O principal fluxo de validação da segurança de referência inclui a execução dos blocos básicos, a geração de estados posteriores, a fusão dos estados anterior e posterior, entre outros passos.
Análise de Vulnerabilidades
A vulnerabilidade aparece na função join_ que chama o módulo de segurança. Quando a soma do comprimento dos parâmetros da função e do comprimento das variáveis locais é superior a 256, a utilização do tipo u8 para representar variáveis locais pode levar a um estouro de inteiro.
Embora o Move tenha um processo de verificação do número de locais, no módulo de verificação de limites apenas os locais são verificados, sem incluir o comprimento dos parâmetros. Os desenvolvedores parecem ter percebido a necessidade de verificar a soma dos parâmetros e dos valores locais, mas o código apenas verifica o número de variáveis locais.
De estouro de inteiro a ataque DoS
Utilizando esta vulnerabilidade de estouro de inteiro, o atacante pode criar um bloco de código em loop que altera o estado do bloco. 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 resultará em um ataque DoS.
No módulo reference safety, os códigos de operação como MoveLoc/CopyLoc/FreeRef podem desencadear essa situação. Por exemplo, na função copy_loc, se o LocalIndex não existir, isso resultará em panic, levando assim à falha de todo o nó.
Reproduzindo a Vulnerabilidade
Pode reproduzir esta vulnerabilidade no git com o seguinte código PoC:
mover
função pública test(a: u64, b: u64, c: u64, d: u64) {
let x = 0;
loop {
se (x == 1) {
pausa
};
x = x + 1;
}
}
Os passos para desencadear um DoS são os seguintes:
Na primeira execução da função execute_block, os parâmetros e os locais são ambos definidos como SignatureIndex(0), resultando em num_locals igual a 264. Após a execução da função join_, o novo comprimento do mapa de locais torna-se 8.
Na segunda execução da função execute_block, a primeira instrução do código move executa copyloc(57). Como nesta altura o locals tem apenas comprimento 8, o offset 57 não existe, levando a que a função get(57).unwrap() retorne None, o que provoca uma panic no final.
Resumo
Esta vulnerabilidade indica que não existe código absolutamente seguro. Embora a linguagem Move realize verificações estáticas antes da execução do código, ainda pode ser contornada por vulnerabilidades de estouro. Isso reforça mais uma vez a importância da auditoria de código.
Para a linguagem Move, sugerimos adicionar mais código de verificação em tempo de execução para evitar situações inesperadas. Atualmente, a verificação de segurança na Move ocorre principalmente na fase de verificação, mas uma vez que a verificação é contornada, a falta de reforço de segurança suficiente na fase de execução pode levar a problemas mais graves.
Como líderes na pesquisa de segurança da linguagem Move, continuaremos a investigar profundamente os problemas de segurança do Move e compartilharemos mais descobertas posteriormente.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
18 gostos
Recompensa
18
4
Republicar
Partilhar
Comentar
0/400
PretendingToReadDocs
· 08-15 17:34
move ainda é um problema
Ver originalResponder0
WalletDetective
· 08-14 07:06
Depois de analisar bem, essa vulnerabilidade tem alguma coisa.
Análise de vulnerabilidades de estouro de inteiros na linguagem Move: da segurança de referência ao ataque DoS
Análise de vulnerabilidades de estouro de inteiro na linguagem Move
Introdução
Após uma pesquisa aprofundada sobre o Aptos Moveevm, descobrimos uma nova vulnerabilidade de estouro de inteiro. O processo de ativação dessa vulnerabilidade é relativamente mais interessante, a seguir faremos uma análise aprofundada dessa vulnerabilidade e apresentaremos algumas informações de fundo sobre a linguagem Move. Através da explicação deste artigo, acreditamos que você terá uma compreensão mais profunda da linguagem Move.
A linguagem Move valida as unidades de código antes de executar o bytecode. O processo de validação é dividido em 4 etapas, e essa vulnerabilidade ocorre na etapa de reference_safety.
Segurança de referência em Move
A linguagem Move suporta dois tipos de referências: referências imutáveis (&) e referências mutáveis (&mut). As referências imutáveis são usadas para ler dados de uma estrutura, enquanto as referências mutáveis são usadas para modificar dados. Usar o tipo de referência apropriado ajuda a manter a segurança e a identificar os módulos de leitura.
No módulo de segurança de referência do Move, as instruções de bytecode dos blocos básicos dentro das funções são analisadas para verificar se todas as operações de referência são legais. O principal fluxo de validação da segurança de referência inclui a execução dos blocos básicos, a geração de estados posteriores, a fusão dos estados anterior e posterior, entre outros passos.
Análise de Vulnerabilidades
A vulnerabilidade aparece na função join_ que chama o módulo de segurança. Quando a soma do comprimento dos parâmetros da função e do comprimento das variáveis locais é superior a 256, a utilização do tipo u8 para representar variáveis locais pode levar a um estouro de inteiro.
Embora o Move tenha um processo de verificação do número de locais, no módulo de verificação de limites apenas os locais são verificados, sem incluir o comprimento dos parâmetros. Os desenvolvedores parecem ter percebido a necessidade de verificar a soma dos parâmetros e dos valores locais, mas o código apenas verifica o número de variáveis locais.
De estouro de inteiro a ataque DoS
Utilizando esta vulnerabilidade de estouro de inteiro, o atacante pode criar um bloco de código em loop que altera o estado do bloco. 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 resultará em um ataque DoS.
No módulo reference safety, os códigos de operação como MoveLoc/CopyLoc/FreeRef podem desencadear essa situação. Por exemplo, na função copy_loc, se o LocalIndex não existir, isso resultará em panic, levando assim à falha de todo o nó.
Reproduzindo a Vulnerabilidade
Pode reproduzir esta vulnerabilidade no git com o seguinte código PoC:
mover função pública test(a: u64, b: u64, c: u64, d: u64) { let x = 0; loop { se (x == 1) { pausa }; x = x + 1; } }
Os passos para desencadear um DoS são os seguintes:
Na primeira execução da função execute_block, os parâmetros e os locais são ambos definidos como SignatureIndex(0), resultando em num_locals igual a 264. Após a execução da função join_, o novo comprimento do mapa de locais torna-se 8.
Na segunda execução da função execute_block, a primeira instrução do código move executa copyloc(57). Como nesta altura o locals tem apenas comprimento 8, o offset 57 não existe, levando a que a função get(57).unwrap() retorne None, o que provoca uma panic no final.
Resumo
Esta vulnerabilidade indica que não existe código absolutamente seguro. Embora a linguagem Move realize verificações estáticas antes da execução do código, ainda pode ser contornada por vulnerabilidades de estouro. Isso reforça mais uma vez a importância da auditoria de código.
Para a linguagem Move, sugerimos adicionar mais código de verificação em tempo de execução para evitar situações inesperadas. Atualmente, a verificação de segurança na Move ocorre principalmente na fase de verificação, mas uma vez que a verificação é contornada, a falta de reforço de segurança suficiente na fase de execução pode levar a problemas mais graves.
Como líderes na pesquisa de segurança da linguagem Move, continuaremos a investigar profundamente os problemas de segurança do Move e compartilharemos mais descobertas posteriormente.