解讀技術大佬對Cetus Protocol黑客攻擊事件的分析

robot
摘要生成中

通俗版本:簡單“翻譯”解讀下技術大佬關於 @CetusProtocol

黑客攻擊事件的分析:

這次攻擊暴露的是一個經典的整數溢出問題,具體表現爲類型轉換過程中的數據截斷。

技術細節拆解:

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位直接消失。攻擊者正是利用了這種"計算精度缺失"漏洞。

需要明確一點:這次漏洞與 @SuiNetwork 的底層安全架構無關,屬於Move語言的安全性“榮光”暫時還可信。Why?

Move語言在資源管理和類型安全方面確實具備顯著優勢,能夠有效防範雙重支付、資源泄露等底層安全問題。但此次Cetus協議出現的是應用邏輯層面的數學計算錯誤,並非Move語言本身的設計缺陷。

具體而言,Move的類型系統雖然嚴格,但對於顯式類型轉換(explicit casting)操作,仍需依賴開發者的正確判斷。當程序主動執行u256到u64的類型轉換時,編譯器無法判斷這是有意設計還是邏輯錯誤。

此外,這次安全事件與Sui的共識機制、交易處理、狀態管理等核心底層功能完全無關。Sui Network只是忠實執行了Cetus協議提交的交易指令,漏洞源於應用層協議本身的邏輯缺陷。

說白了,再先進的編程語言也無法完全杜絕應用層的邏輯錯誤。Move能夠防範大部分底層安全風險,但無法代替開發者進行業務邏輯的邊界檢查和數學運算的溢出保護。

更正:

跟大佬進一步溝通了下,此前對 @CetusProtocol 黑客攻擊的技術分析在具體細節上存在偏差,特此更正。

此前準確識別了這是一個數學計算溢出類漏洞,攻擊者通過構造特殊數值"以小博大"的核心邏輯是對的,對大家關心的Move語言的安全性疑惑解答也是對的。

只不過看到了數學計算錯誤的現象,推測是類型轉換問題,但實際是其他函數的邊界檢查問題。事實上,Move語言對u256到u64等類型轉換有嚴格的審查機制,這類顯式轉換在正常情況下確實會有安全檢查。

具體的漏洞位置和技術實現機制需要修正,如下。

真正的問題出現在get\_delta\_a函數的溢出檢查機制失效:

1)函數作用:計算添加指定流動性時需要的token A數量;

2)關鍵缺陷:checked\_shlw函數的溢出檢查存在編碼錯誤,未能阻止無效的大流動性值;

3)攻擊利用:黑客構造特殊流動性值,繞過失效檢查,最終通過div\_round的向上取整機制,讓所需token A數量變成14)。

攻擊效果:用1個token A鑄造巨額流動性,然後抽幹資金池。

查看原文
本頁面內容僅供參考,非招攬或要約,也不提供投資、稅務或法律諮詢。詳見聲明了解更多風險披露。
  • 讚賞
  • 留言
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate APP
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)