Versão simplificada: uma interpretação simples da "tradução" sobre o pro @CetusProtocol
Análise de incidentes de ataque hacker:
Este ataque expôs um clássico problema de estouro de inteiro, manifestando-se especificamente como uma truncagem de dados durante o processo de conversão de tipos.
Detalhamento dos detalhes técnicos:
Localização de vulnerabilidades: O problema ocorre no mecanismo de conversão de tipos da função get_amount_by_liquidity, onde a conversão forçada de u256 para u64 resulta na perda de dados de alta ordem.
2）Fluxo de ataque:
O atacante passa um parâmetro de quantidade de liquidez extremamente alta através da função add_liquidity;
2、O sistema chama a função get_delta_b para calcular a quantidade necessária de tokens B;
Durante o processo de cálculo, a multiplicação de dois dados do tipo u128 deve resultar teoricamente em um tipo u256;
Defeito crítico: a conversão forçada do resultado u256 para u64 ao retornar da função resulta na truncagem dos 128 bits mais altos dos dados.
3）Efeito de utilização: O montante de liquidez que originalmente exigia uma grande quantidade de tokens para ser cunhado, agora pode ser completado com uma quantidade muito pequena de tokens. O atacante obtém uma grande parte da liquidez a um custo extremamente baixo e, em seguida, realiza arbitragem no fundo, destruindo parte da liquidez.
Uma analogia simples: é como calcular 1 bilhão × 1 bilhão com uma calculadora que só pode mostrar 8 dígitos; o resultado de 20 dígitos só pode mostrar os últimos 8, enquanto os primeiros 12 simplesmente desaparecem. O atacante aproveitou essa vulnerabilidade de "falta de precisão no cálculo".
É preciso deixar claro: esta falha não está relacionada com a arquitetura de segurança subjacente do @SuiNetwork, a "glória" da segurança da linguagem Move ainda é temporariamente confiável. Por quê?
A linguagem Move realmente possui vantagens significativas em gestão de recursos e segurança de tipos, sendo capaz de prevenir efetivamente problemas de segurança de baixo nível, como duplo gasto e vazamento de recursos. No entanto, o que ocorreu com o protocolo Cetus foi um erro de cálculo matemático no nível da lógica de aplicação, e não uma falha de design da própria linguagem Move.
Especificamente, embora o sistema de tipos do Move seja rigoroso, para operações de conversão de tipos explícitas (explicit casting), ainda depende do julgamento correto do desenvolvedor. Quando o programa executa ativamente a conversão de tipo de u256 para u64, o compilador não consegue determinar se isso foi intencional ou um erro lógico.
Além disso, este incidente de segurança não tem qualquer relação com o mecanismo de consenso, o processamento de transações, a gestão de estado e outras funções fundamentais do Sui. A Sui Network apenas executou fielmente as instruções de transação apresentadas pelo protocolo Cetus, e a vulnerabilidade vem de uma falha lógica do próprio protocolo da camada de aplicação.
Dito de forma simples, nenhuma linguagem de programação, por mais avançada que seja, consegue eliminar completamente os erros lógicos na camada de aplicação. O Move pode prevenir a maioria dos riscos de segurança na camada inferior, mas não pode substituir os desenvolvedores na verificação das fronteiras da lógica de negócios e na proteção contra estouros em cálculos matemáticos.
Correção:
Conversei mais com o pro, e a análise técnica do ataque hacker ao @CetusProtocol tinha algumas discrepâncias nos detalhes específicos, portanto, venho corrigir isso.
Anteriormente, foi identificada com precisão que esta é uma vulnerabilidade do tipo estouro de cálculo matemático, onde o atacante constrói valores especiais. A lógica central "apostar pouco para ganhar muito" está correta, e a resposta às preocupações sobre a segurança da linguagem Move também está correta.
Apenas observei o fenômeno de erro de cálculo matemático e supus que era um problema de conversão de tipos, mas na verdade era um problema de verificação de limites de outras funções. De fato, a linguagem Move tem um mecanismo de verificação rigoroso para a conversão de tipos como de u256 para u64, e essas conversões explícitas realmente passam por verificações de segurança em condições normais.
Os locais específicos das vulnerabilidades e os mecanismos de implementação técnica precisam ser corrigidos, como segue.
O verdadeiro problema surge na falha do mecanismo de verificação de estouro da função get\_delta\_a:
Função: calcular a quantidade de token A necessária ao adicionar liquidez especificada;
2）Defeito chave: a verificação de estouro da função checked\_shlw contém um erro de codificação, não conseguiu impedir valores de liquidez excessivos e inválidos;
3）Ataque de utilização: hackers constroem valores de liquidez especiais, contornando a verificação de falhas, e, finalmente, através do mecanismo de arredondamento para cima de div\_round, fazem com que a quantidade necessária do token A se torne 14).
Efeito do ataque: usar 1 token A para criar uma enorme liquidez e, em seguida, drenar o fundo.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Interpretação da análise do pro sobre o ataque hacker ao Cetus Protocol
Versão simplificada: uma interpretação simples da "tradução" sobre o pro @CetusProtocol
Análise de incidentes de ataque hacker:
Este ataque expôs um clássico problema de estouro de inteiro, manifestando-se especificamente como uma truncagem de dados durante o processo de conversão de tipos.
Detalhamento dos detalhes técnicos:
2）Fluxo de ataque:
2、O sistema chama a função get_delta_b para calcular a quantidade necessária de tokens B;
Defeito crítico: a conversão forçada do resultado u256 para u64 ao retornar da função resulta na truncagem dos 128 bits mais altos dos dados.
3）Efeito de utilização: O montante de liquidez que originalmente exigia uma grande quantidade de tokens para ser cunhado, agora pode ser completado com uma quantidade muito pequena de tokens. O atacante obtém uma grande parte da liquidez a um custo extremamente baixo e, em seguida, realiza arbitragem no fundo, destruindo parte da liquidez.
Uma analogia simples: é como calcular 1 bilhão × 1 bilhão com uma calculadora que só pode mostrar 8 dígitos; o resultado de 20 dígitos só pode mostrar os últimos 8, enquanto os primeiros 12 simplesmente desaparecem. O atacante aproveitou essa vulnerabilidade de "falta de precisão no cálculo".
É preciso deixar claro: esta falha não está relacionada com a arquitetura de segurança subjacente do @SuiNetwork, a "glória" da segurança da linguagem Move ainda é temporariamente confiável. Por quê?
A linguagem Move realmente possui vantagens significativas em gestão de recursos e segurança de tipos, sendo capaz de prevenir efetivamente problemas de segurança de baixo nível, como duplo gasto e vazamento de recursos. No entanto, o que ocorreu com o protocolo Cetus foi um erro de cálculo matemático no nível da lógica de aplicação, e não uma falha de design da própria linguagem Move.
Especificamente, embora o sistema de tipos do Move seja rigoroso, para operações de conversão de tipos explícitas (explicit casting), ainda depende do julgamento correto do desenvolvedor. Quando o programa executa ativamente a conversão de tipo de u256 para u64, o compilador não consegue determinar se isso foi intencional ou um erro lógico.
Além disso, este incidente de segurança não tem qualquer relação com o mecanismo de consenso, o processamento de transações, a gestão de estado e outras funções fundamentais do Sui. A Sui Network apenas executou fielmente as instruções de transação apresentadas pelo protocolo Cetus, e a vulnerabilidade vem de uma falha lógica do próprio protocolo da camada de aplicação.
Dito de forma simples, nenhuma linguagem de programação, por mais avançada que seja, consegue eliminar completamente os erros lógicos na camada de aplicação. O Move pode prevenir a maioria dos riscos de segurança na camada inferior, mas não pode substituir os desenvolvedores na verificação das fronteiras da lógica de negócios e na proteção contra estouros em cálculos matemáticos.
Correção:
Conversei mais com o pro, e a análise técnica do ataque hacker ao @CetusProtocol tinha algumas discrepâncias nos detalhes específicos, portanto, venho corrigir isso.
Anteriormente, foi identificada com precisão que esta é uma vulnerabilidade do tipo estouro de cálculo matemático, onde o atacante constrói valores especiais. A lógica central "apostar pouco para ganhar muito" está correta, e a resposta às preocupações sobre a segurança da linguagem Move também está correta.
Apenas observei o fenômeno de erro de cálculo matemático e supus que era um problema de conversão de tipos, mas na verdade era um problema de verificação de limites de outras funções. De fato, a linguagem Move tem um mecanismo de verificação rigoroso para a conversão de tipos como de u256 para u64, e essas conversões explícitas realmente passam por verificações de segurança em condições normais.
Os locais específicos das vulnerabilidades e os mecanismos de implementação técnica precisam ser corrigidos, como segue.
O verdadeiro problema surge na falha do mecanismo de verificação de estouro da função
get\_delta\_a:2）Defeito chave: a verificação de estouro da função
checked\_shlwcontém um erro de codificação, não conseguiu impedir valores de liquidez excessivos e inválidos;3）Ataque de utilização: hackers constroem valores de liquidez especiais, contornando a verificação de falhas, e, finalmente, através do mecanismo de arredondamento para cima de
div\_round, fazem com que a quantidade necessária do token A se torne 14).Efeito do ataque: usar 1 token A para criar uma enorme liquidez e, em seguida, drenar o fundo.