1、Kẻ tấn công truyền vào tham số số lượng thanh khoản cực lớn thông qua hàm add_liquidity; 2. Hệ thống gọi hàm get_delta_b để tính toán số lượng B token cần thiết; 3. Trong quá trình tính toán, khi hai dữ liệu loại u128 được nhân với nhau, kết quả lý thuyết nên thuộc loại u256;
Khuyết điểm chính: Hàm chuyển đổi kết quả u256 thành u64 khi trả về, dẫn đến việc dữ liệu 128 bit cao bị cắt ngắn.
3) Hiệu quả sử dụng: Trước đây, cần một lượng lớn token để đúc khối lượng thanh khoản, giờ đây chỉ cần một lượng rất nhỏ token là có thể hoàn thành. Kẻ tấn công có thể đạt được khối lượng thanh khoản khổng lồ với chi phí rất thấp, sau đó thực hiện chênh lệch giá quỹ bằng cách phá hủy một phần thanh khoản.
Cụ thể, hệ thống kiểu của Move mặc dù nghiêm ngặt, nhưng đối với các thao tác chuyển đổi kiểu rõ ràng (explicit casting), vẫn cần dựa vào sự phán đoán đúng đắn của nhà phát triển. Khi chương trình chủ động thực hiện chuyển đổi kiểu từ u256 sang u64, trình biên dịch không thể xác định đây là thiết kế có chủ ý hay lỗi logic.
Ngoài ra, sự kiện an ninh lần này hoàn toàn không liên quan đến cơ chế đồng thuận, xử lý giao dịch, quản lý trạng thái và các chức năng cốt lõi khác của Sui. Mạng Sui chỉ thực hiện trung thành các lệnh giao dịch được gửi từ giao thức Cetus, lỗ hổng xuất phát từ các lỗi logic của chính giao thức ứng dụng.
Nói một cách đơn giản, không có ngôn ngữ lập trình nào tiên tiến đến mức có thể hoàn toàn loại bỏ lỗi logic ở tầng ứng dụng. Move có thể ngăn chặn hầu hết các rủi ro an ninh ở tầng dưới, nhưng không thể thay thế các nhà phát triển trong việc kiểm tra biên giới của logic kinh doanh và bảo vệ chống tràn số trong các phép toán.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
这次攻击暴露是一个经典的整数溢出问题,具体表现为类型转换过程中的数据截断。
Chi tiết kỹ thuật phân tích:
1)漏洞定位:问题出现在get_amount_by_liquidity函数的类型转换机制中,从u256到u64的强制转换导致高位数据丢失。
2）Quy trình tấn công:
1、Kẻ tấn công truyền vào tham số số lượng thanh khoản cực lớn thông qua hàm add_liquidity;
2. Hệ thống gọi hàm get_delta_b để tính toán số lượng B token cần thiết;
3. Trong quá trình tính toán, khi hai dữ liệu loại u128 được nhân với nhau, kết quả lý thuyết nên thuộc loại u256;
Khuyết điểm chính: Hàm chuyển đổi kết quả u256 thành u64 khi trả về, dẫn đến việc dữ liệu 128 bit cao bị cắt ngắn.
3) Hiệu quả sử dụng: Trước đây, cần một lượng lớn token để đúc khối lượng thanh khoản, giờ đây chỉ cần một lượng rất nhỏ token là có thể hoàn thành. Kẻ tấn công có thể đạt được khối lượng thanh khoản khổng lồ với chi phí rất thấp, sau đó thực hiện chênh lệch giá quỹ bằng cách phá hủy một phần thanh khoản.
简单类比:就像用只能显示8位数的计算器计算10亿×10亿,20位的计算结果只能显示后8位,前12位直接消失。 攻击者正是利用了这种"计算精度缺少"vulnerability。
Move语言在资源管理和类型安全方面确实具备显有优势,能够有效防范双重支付、资源泄露等底层安全问题。 但此次Cetus协议出现的是应用逻辑层面的数学计算错误,并非Move语言本身的设计缺陷。
Cụ thể, hệ thống kiểu của Move mặc dù nghiêm ngặt, nhưng đối với các thao tác chuyển đổi kiểu rõ ràng (explicit casting), vẫn cần dựa vào sự phán đoán đúng đắn của nhà phát triển. Khi chương trình chủ động thực hiện chuyển đổi kiểu từ u256 sang u64, trình biên dịch không thể xác định đây là thiết kế có chủ ý hay lỗi logic.
Ngoài ra, sự kiện an ninh lần này hoàn toàn không liên quan đến cơ chế đồng thuận, xử lý giao dịch, quản lý trạng thái và các chức năng cốt lõi khác của Sui. Mạng Sui chỉ thực hiện trung thành các lệnh giao dịch được gửi từ giao thức Cetus, lỗ hổng xuất phát từ các lỗi logic của chính giao thức ứng dụng.
Nói một cách đơn giản, không có ngôn ngữ lập trình nào tiên tiến đến mức có thể hoàn toàn loại bỏ lỗi logic ở tầng ứng dụng. Move có thể ngăn chặn hầu hết các rủi ro an ninh ở tầng dưới, nhưng không thể thay thế các nhà phát triển trong việc kiểm tra biên giới của logic kinh doanh và bảo vệ chống tràn số trong các phép toán.