A linguagem Move apresenta novamente uma vulnerabilidade crítica: o estouro de inteiro pode causar a falha do nó
Recentemente, investigadores de segurança descobriram uma nova vulnerabilidade de estouro de inteiro ao analisar profundamente o Aptos Moveevm. Esta vulnerabilidade está presente no processo de verificação de segurança de referências da linguagem Move, podendo levar à falha do nó.
A linguagem Move realiza a verificação de código antes da execução do bytecode, dividindo-se em 4 etapas. Esta vulnerabilidade ocorre na etapa reference_safety. Esta etapa é principalmente utilizada para verificar a segurança das referências, incluindo a verificação da existência de referências pendentes e se o acesso a referências mutáveis é seguro.
O processo de verificação irá percorrer cada bloco básico e realizar uma análise. Um bloco básico refere-se a uma sequência de código sem instruções de ramificação, exceto por entradas e saídas. A linguagem Move identifica blocos básicos através da busca por instruções de ramificação e de loop.
Ao verificar a segurança da referência, mantém-se uma estrutura AbstractState, que contém informações sobre o grafo de empréstimos e locais. O processo de verificação executará o código do bloco básico, gerando o estado após a execução, que será então mesclado com o estado anterior, atualizando o estado do bloco e propagando-o para os blocos subsequentes.
A vulnerabilidade ocorre na função join_. Essa função é utilizada para mesclar o estado antes e depois da execução, atualizando os locais e o gráfico de empréstimo. Quando a soma do comprimento dos parâmetros e o comprimento das variáveis locais é maior que 256, devido ao uso do tipo u8 para iterar os locais, resulta em um estouro de inteiro.
Utilizar este overflow pode alterar o estado do bloco básico. Em códigos com loops, ao executar várias vezes o mesmo bloco básico, pode-se aceder a um índice de locals que não existe, levando a um panic que causa a falha do nó.
Os pesquisadores forneceram um código PoC que, ao definir parâmetros específicos e a quantidade de variáveis locais, provoca um estouro de inteiro, levando finalmente a um panic.
Esta vulnerabilidade expôs que mesmo linguagens que valorizam a segurança como a Move podem ter falhas. Recomenda-se que os designers da linguagem Move adicionem mais verificações de segurança em tempo de execução, em vez de depender apenas das verificações na fase de validação. Isto também destaca a importância da auditoria de código.
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.
Vulnerabilidade de estouro de inteiro na linguagem Move: risco de referência à verificação de segurança
A linguagem Move apresenta novamente uma vulnerabilidade crítica: o estouro de inteiro pode causar a falha do nó
Recentemente, investigadores de segurança descobriram uma nova vulnerabilidade de estouro de inteiro ao analisar profundamente o Aptos Moveevm. Esta vulnerabilidade está presente no processo de verificação de segurança de referências da linguagem Move, podendo levar à falha do nó.
A linguagem Move realiza a verificação de código antes da execução do bytecode, dividindo-se em 4 etapas. Esta vulnerabilidade ocorre na etapa reference_safety. Esta etapa é principalmente utilizada para verificar a segurança das referências, incluindo a verificação da existência de referências pendentes e se o acesso a referências mutáveis é seguro.
O processo de verificação irá percorrer cada bloco básico e realizar uma análise. Um bloco básico refere-se a uma sequência de código sem instruções de ramificação, exceto por entradas e saídas. A linguagem Move identifica blocos básicos através da busca por instruções de ramificação e de loop.
Ao verificar a segurança da referência, mantém-se uma estrutura AbstractState, que contém informações sobre o grafo de empréstimos e locais. O processo de verificação executará o código do bloco básico, gerando o estado após a execução, que será então mesclado com o estado anterior, atualizando o estado do bloco e propagando-o para os blocos subsequentes.
A vulnerabilidade ocorre na função join_. Essa função é utilizada para mesclar o estado antes e depois da execução, atualizando os locais e o gráfico de empréstimo. Quando a soma do comprimento dos parâmetros e o comprimento das variáveis locais é maior que 256, devido ao uso do tipo u8 para iterar os locais, resulta em um estouro de inteiro.
Utilizar este overflow pode alterar o estado do bloco básico. Em códigos com loops, ao executar várias vezes o mesmo bloco básico, pode-se aceder a um índice de locals que não existe, levando a um panic que causa a falha do nó.
Os pesquisadores forneceram um código PoC que, ao definir parâmetros específicos e a quantidade de variáveis locais, provoca um estouro de inteiro, levando finalmente a um panic.
Esta vulnerabilidade expôs que mesmo linguagens que valorizam a segurança como a Move podem ter falhas. Recomenda-se que os designers da linguagem Move adicionem mais verificações de segurança em tempo de execução, em vez de depender apenas das verificações na fase de validação. Isto também destaca a importância da auditoria de código.