1) Локализация уязвимости: Проблема возникает в механизме преобразования типов функции get_amount_by_liquidity, где принудительное преобразование из u256 в u64 приводит к потере верхних бит данных.
2) Процесс атаки:
1. Нападающий передает чрезвычайно большое количество параметров ликвидности через функцию add_liquidity; 2. Система вызывает функцию get_delta_b для вычисления необходимого количества токенов B; 3. В процессе вычислений произведение двух данных типа u128 должно теоретически давать результат типа u256;
Ключевой дефект: принудительное преобразование результата u256 в u64 при возврате функции приводит к обрезке старших 128 бит данных.
3) Эффективность использования: для создания ликвидности раньше требовалось огромное количество токенов, теперь же достаточно очень небольшого количества токенов. Атакующие получают огромные доли ликвидности с очень низкими затратами, а затем реализуют арбитраж фондового пула, уничтожая часть ликвидности.
Язык Move действительно обладает значительными преимуществами в управлении ресурсами и типовой безопасности, что позволяет эффективно предотвращать проблемы низкоуровневой безопасности, такие как двойные расходы и утечки ресурсов. Однако ошибка, возникшая в протоколе Cetus, связана с математическими вычислениями на уровне логики приложений, а не с самим дизайном языка Move.
Конкретно говоря, хотя система типов Move строгая, она все равно зависит от правильного суждения разработчика для операций явного приведения типов (explicit casting). Когда программа активно выполняет приведение типа u256 к u64, компилятор не может определить, было ли это намеренным дизайном или логической ошибкой.
Кроме того, данное инцидент безопасности совершенно не связано с механизмом консенсуса Sui, обработкой транзакций, управлением состоянием и другими основными функциональными особенностями. Sui Network просто верно выполнил инструкции по транзакциям, представленные протоколом Cetus, а уязвимость возникла из логических ошибок самого прикладного протокола.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
这次攻击暴露是一个经典的整数溢出问题,具体表现为类型转换过程中的数据截断。
Технические детали разборки:
1) Локализация уязвимости: Проблема возникает в механизме преобразования типов функции get_amount_by_liquidity, где принудительное преобразование из u256 в u64 приводит к потере верхних бит данных.
2) Процесс атаки:
1. Нападающий передает чрезвычайно большое количество параметров ликвидности через функцию add_liquidity;
2. Система вызывает функцию get_delta_b для вычисления необходимого количества токенов B;
3. В процессе вычислений произведение двух данных типа u128 должно теоретически давать результат типа u256;
Ключевой дефект: принудительное преобразование результата u256 в u64 при возврате функции приводит к обрезке старших 128 бит данных.
3) Эффективность использования: для создания ликвидности раньше требовалось огромное количество токенов, теперь же достаточно очень небольшого количества токенов. Атакующие получают огромные доли ликвидности с очень низкими затратами, а затем реализуют арбитраж фондового пула, уничтожая часть ликвидности.
简单类比:就像用只能显示8位数的计算器计算10亿×10亿,20位的计算结果只能显示后8位,前12位直接消失。 攻击者正是利用了这种"计算精度缺少"vulnerability。
Язык Move действительно обладает значительными преимуществами в управлении ресурсами и типовой безопасности, что позволяет эффективно предотвращать проблемы низкоуровневой безопасности, такие как двойные расходы и утечки ресурсов. Однако ошибка, возникшая в протоколе Cetus, связана с математическими вычислениями на уровне логики приложений, а не с самим дизайном языка Move.
Конкретно говоря, хотя система типов Move строгая, она все равно зависит от правильного суждения разработчика для операций явного приведения типов (explicit casting). Когда программа активно выполняет приведение типа u256 к u64, компилятор не может определить, было ли это намеренным дизайном или логической ошибкой.
Кроме того, данное инцидент безопасности совершенно не связано с механизмом консенсуса Sui, обработкой транзакций, управлением состоянием и другими основными функциональными особенностями. Sui Network просто верно выполнил инструкции по транзакциям, представленные протоколом Cetus, а уязвимость возникла из логических ошибок самого прикладного протокола.
说白了,再先进的编程语言也无法完全杜绝应用层的逻辑错误。 Move能够防范大部分底层安全风险,但无法代替开发者进行业务逻辑的边界检查和数学运算的溢出保护。