Цього разу атака виявила класичну проблему переповнення цілих чисел, що проявляється у втраті даних під час процесу перетворення типів.

Технічні деталі розбору:

1)漏洞定位:问题出现在get_amount_by_liquidity函数的类型转换机制中,从u256到u64的强制转换导致高位数据丢失。

2) Процес атаки:

1. Зловмисник передає надзвичайно велику кількість параметрів ліквідності через функцію add_liquidity.
2. Система викликає функцію get_delta_b для розрахунку необхідної кількості токенів B;
3. Під час обчислення, при множенні двох даних типу u128, теоретичний результат має бути типу u256;

关键缺陷:函数返回时将u256结果强制转换为u64,导致高位128位数据被截断。

3)利用效果:原需要大量代币才能铸造的流动性额度,现在仅需极少量代币即可完成。 攻击者以极низька ціна 获得giant 额流动性份额,随后通过销毁部分流动性实现资金池套利。

简单类比:就像用只能显示8位数的计算器计算10亿×10亿,20位的计算结果只能显示后8位,前12位直接消失。 攻击者正是利用了这种"计算精度缺少"вразливість。

Мова Move дійсно має суттєві переваги в управлінні ресурсами та типобезпеці, що дозволяє ефективно запобігати проблемам безпеки на нижньому рівні, таким як подвійні витрати та витік ресурсів. Однак, у випадку з протоколом Cetus виникла помилка математичних обчислень на рівні прикладної логіки, а не дефект у самій конструкції мови Move.

具体而言,Move的类型系统虽然严格,但对于显式类型转换(explicit casting)操作,仍需依赖开发者的正确判断。 当程序主动执行u256到u64的类型转换时,编译器无法判断这是有意设计还是逻辑错误。

此外,这次安全事件与Sui的共识机制、交易处理、状态管理等核心底层功能完全无关。 Sui Network只是忠实执行了Cetus协议提交的交易指令,漏洞源于应用层协议本身的逻辑缺陷。

说白了,再先进的编程语言也无法完全杜绝应用层的逻辑错误。 Move能够防范大部分底层安全风险,但无法代替开发者进行业务逻辑的边界检查和数学运算的溢出保护。