EOS智能合約被爆整型溢出等漏洞，可致交易歸零！

編者按：這段時間EOS真不消停，一波未平一波又起，先是被大佬說傳銷幣，接著是價格大幅跳水，猛如虎的安全公司也沒閑著，接連爆出安全漏洞。

這不，剛緩了幾天，又被發現了合約上的漏洞——EOS代幣合約存在整型溢出等問題，部分合約實現不夠嚴謹。這一問題嚴重時可能會引發交易所市值歸零，給項目方、Token持有者帶來慘痛且不可挽回的損失。

今天，我們邀請了成都鏈安科技CEO楊霞，就EOS的這一安全漏洞從技術上進行解析。同時，給開發者一些切實的指引，以免承受巨額損失。

最近，我們在審計客戶合約時發現：EOS代幣合約存在整型溢出等問題，部分合約實現不夠嚴謹。

具體包括：

整型溢出錯誤；

許可權檢查不嚴謹；

API函數的不規範使用；

常規代碼錯誤。

為了使開發者在合約開發中不掉進坑裡，我們接下來就一一對上述問題進行分析。並且給出合理的解決辦法，讓開發者不至被黑客利用。

讓我們直奔主題。

問題出在EOS的代幣合約

這次漏洞的主要原因，在於EOS的代幣合約有不嚴謹之處，主要體現在以下4個方面：

1. 整體型溢出錯誤

使用自己的數據結構描述代幣，對代幣數值進行算數運算時未進行安全檢查。在誤操作時容易產生整型溢出錯誤，可能導致代幣量歸零甚至變成負數的嚴重後果！

2. 許可權檢查不嚴謹

許可權檢查不嚴謹，造成邏輯漏洞。部分代幣合約設置了「凍結賬戶和代幣」的功能，然而EOS卻將檢查 「凍結」 的代碼放在transfer（轉賬）函數中，從而導致執行issue（發行代幣）的時候不受「凍結」狀態影響，可以任意增發代幣。參考以下代碼。

3. API函數的不規範使用

這裡指的是開發者要注意EOS API函數的參數類型。

例如：string_to_symbol（uint8_t , const char *），

第一個參數傳入的整型變數需要小於256，若使用該API前未對輸入進行檢查，則可能導致整型溢出，從而導致操作了錯誤類型的代幣，帶來嚴重後果。

4. 常見代碼錯誤

資料庫API使用不嚴謹，如multi_index中提供的get和find。其中get會檢查數據是否查詢成功，數據未找到則斷言退出，而find不會檢查數據查詢情況，需要用戶自行判斷，如果缺少判斷直接使用將會導致指針使用問題。

不要慌！關鍵時刻拿走這三根救命稻草

既然EOS代幣合約存在不嚴謹之處，那麼作為項目方應該如何去防範後期可能造成的風險呢？我們給出下面三種建議方法。

第一，合約中使用官方提供的asset數據結構描述代幣，對代幣的算數運算同樣利用asset完成。參考以下代碼：

第二，在使用multi_index的find函數時，一定要進行返回值的檢查。

第三，對所有輸入都通過斷言檢查有效性，調用API函數前，檢查參數類型和大小。

最後，建議代幣合約參照EOS官方給出的eosio.token示例進行實現，避免疏忽而導致的安全檢查不完備。

此漏洞應引起開發者重視

雖然目前EOS代幣合約還沒有上線，但是項目方一定不能掉以輕心，反而應該時刻記住BEC這類事件的慘痛教訓，避免重蹈覆轍，以及整型溢出問題引發的代幣被盜事件的發生。

總體而言，我認為從目前審計EOS代幣合約所遇到的問題來看，開發者在合約敏感代碼（如操作代幣數額）前後，一定要做好參數限制和許可權檢查，使用EOS API時一定要搞清楚該函數的輸入限制和返回值形式，同時多多參考官方的示例實現。

另一方面，智能合約安全是整個區塊鏈行業的基礎設施最底層的保障，項目方合約開發完成後進行安全審計也是很有必要的，從多角度分析合約代碼，找出那些容易忽略的問題，並且做到防患於未然。

關於作者：

楊霞，成都鏈安科技CEO，創始人。電子科技大學副教授，最早研究區塊鏈形式化驗證的專家。一直為航空航天、軍事領域提供形式化驗證服務。主持國家核高基、裝發重大軟體課題等近10項國家課題。CC國際安全標準成員、CCF區塊鏈專委會委員。發表學術論文30多篇，申請20多項專利。

了解更多區塊鏈技術及應用內容

敬請關註：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！