Análise da vulnerabilidade de estouro de inteiro na verificação de segurança de referência 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 o processo de ativação é bastante interessante. Este artigo fará uma análise aprofundada dessa vulnerabilidade e explorará alguns conhecimentos de fundo relacionados à linguagem Move.
A linguagem Move realiza a verificação da unidade de código antes da execução do bytecode, dividida em quatro etapas. Esta vulnerabilidade ocorre na etapa reference_safety.
O módulo de validação de referência de segurança define uma função de transferência usada para validar a segurança de referência do sujeito do processo. O conteúdo verificado inclui a validação de que não há referências pendentes, se o acesso a referências mutáveis é seguro, se o acesso a referências de armazenamento global é seguro, entre outros.
A função de entrada de verificação de segurança chamada analyze_function será invocada para 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 os blocos básicos percorrendo o bytecode e buscando 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. Referências imutáveis são usadas para ler dados, enquanto referências mutáveis são usadas para modificar dados. O uso adequado dos tipos de referências ajuda a manter a segurança e a identificar os módulos de leitura.
O módulo de segurança de referências irá escanear as instruções de bytecode dos blocos básicos da função, verificando se todas as operações de referência são válidas. O processo de validaçã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.
Durante o processo de verificação, será comparado o estado antes e depois da execução do bloco básico, e a fusão do estado anterior e do estado posterior será feita com base na alteração do join_result. Se houver uma alteração e o bloco atual tiver uma borda retroativa que aponta para si mesmo (indicando a presença de um ciclo), irá retornar ao início do ciclo e continuar a execução desse bloco básico até que o estado posterior seja igual ao estado anterior ou que ocorra uma interrupção devido a um erro.
A falha ocorre no processo de verificação se o resultado do join mudou. Quando a soma do comprimento dos parâmetros e do comprimento das variáveis locais é maior que 256, a utilização do tipo u8 para iterar sobre os locals pode causar um overflow inteiro. Embora o Move tenha um processo para verificar o número de locals, o módulo de verificação de limites apenas verifica os locals, não incluindo o comprimento dos parâmetros.
Esta vulnerabilidade de estouro de inteiro pode levar a ataques de negação de serviço (DoS). Os atacantes podem construir blocos de código de loop e explorar 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 é chamada novamente, a análise da sequência de instruções de bytecode no bloco básico acessará o novo mapa de locais. Se o índice que as instruções precisam acessar não existir no novo mapa de locais do AbstractState, isso resultará em DoS.
Para verificar esta vulnerabilidade, pode-se reproduzir o PoC no git. O bloco de código no PoC contém uma instrução de desvio incondicional, que, sempre que a última instrução é executada, retorna à primeira instrução, causando múltiplas chamadas às funções execute_block e join.
Esta vulnerabilidade demonstra que mesmo linguagens focadas em segurança como Move podem ter falhas de segurança. Ela enfatiza a importância da auditoria de código, ao mesmo tempo que sugere que os designers da linguagem Move adicionem mais verificações de código em tempo de execução para evitar situações inesperadas. Atualmente, o Move realiza verificações de segurança 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íder em 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údo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
20 Curtidas
Recompensa
20
6
Compartilhar
Comentário
0/400
BagHolderTillRetire
· 07-22 09:41
Esse bug é incrível, estou tendo um estouro que causa a queda.
Ver originalResponder0
MetaverseVagabond
· 07-21 19:40
A vulnerabilidade de estouro voltou, que pena.
Ver originalResponder0
HeavenAndEarthAreBle
· 07-20 02:27
Foda-se
Ver originalResponder0
MemeTokenGenius
· 07-20 00:50
Ai, este bug realmente explodiu.
Ver originalResponder0
GamefiHarvester
· 07-20 00:43
Ainda não vão consertar a tempo? Os idiotas de ferro estão a esperar para fazer as pessoas de parvas.
Foi descoberta uma nova vulnerabilidade de overflow de inteiro na verificação de segurança do Move.
Análise da vulnerabilidade de estouro de inteiro na verificação de segurança de referência 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 o processo de ativação é bastante interessante. Este artigo fará uma análise aprofundada dessa vulnerabilidade e explorará alguns conhecimentos de fundo relacionados à linguagem Move.
A linguagem Move realiza a verificação da unidade de código antes da execução do bytecode, dividida em quatro etapas. Esta vulnerabilidade ocorre na etapa reference_safety.
O módulo de validação de referência de segurança define uma função de transferência usada para validar a segurança de referência do sujeito do processo. O conteúdo verificado inclui a validação de que não há referências pendentes, se o acesso a referências mutáveis é seguro, se o acesso a referências de armazenamento global é seguro, entre outros.
A função de entrada de verificação de segurança chamada analyze_function será invocada para 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 os blocos básicos percorrendo o bytecode e buscando 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. Referências imutáveis são usadas para ler dados, enquanto referências mutáveis são usadas para modificar dados. O uso adequado dos tipos de referências ajuda a manter a segurança e a identificar os módulos de leitura.
O módulo de segurança de referências irá escanear as instruções de bytecode dos blocos básicos da função, verificando se todas as operações de referência são válidas. O processo de validaçã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.
Durante o processo de verificação, será comparado o estado antes e depois da execução do bloco básico, e a fusão do estado anterior e do estado posterior será feita com base na alteração do join_result. Se houver uma alteração e o bloco atual tiver uma borda retroativa que aponta para si mesmo (indicando a presença de um ciclo), irá retornar ao início do ciclo e continuar a execução desse bloco básico até que o estado posterior seja igual ao estado anterior ou que ocorra uma interrupção devido a um erro.
A falha ocorre no processo de verificação se o resultado do join mudou. Quando a soma do comprimento dos parâmetros e do comprimento das variáveis locais é maior que 256, a utilização do tipo u8 para iterar sobre os locals pode causar um overflow inteiro. Embora o Move tenha um processo para verificar o número de locals, o módulo de verificação de limites apenas verifica os locals, não incluindo o comprimento dos parâmetros.
Esta vulnerabilidade de estouro de inteiro pode levar a ataques de negação de serviço (DoS). Os atacantes podem construir blocos de código de loop e explorar 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 é chamada novamente, a análise da sequência de instruções de bytecode no bloco básico acessará o novo mapa de locais. Se o índice que as instruções precisam acessar não existir no novo mapa de locais do AbstractState, isso resultará em DoS.
Para verificar esta vulnerabilidade, pode-se reproduzir o PoC no git. O bloco de código no PoC contém uma instrução de desvio incondicional, que, sempre que a última instrução é executada, retorna à primeira instrução, causando múltiplas chamadas às funções execute_block e join.
Esta vulnerabilidade demonstra que mesmo linguagens focadas em segurança como Move podem ter falhas de segurança. Ela enfatiza a importância da auditoria de código, ao mesmo tempo que sugere que os designers da linguagem Move adicionem mais verificações de código em tempo de execução para evitar situações inesperadas. Atualmente, o Move realiza verificações de segurança 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íder em pesquisa de segurança da linguagem Move, continuaremos a investigar profundamente os problemas de segurança do Move e compartilharemos mais descobertas posteriormente.