在這智能合約漏洞頻出的背景下，又發(fā)現(xiàn)了一個存在嚴(yán)重安全漏洞的智能合約——OnPlace(OPL)！

一直以來“智能合約”漏洞已經(jīng)成為區(qū)塊鏈安全的重災(zāi)區(qū)。攻擊者通過發(fā)布包含惡意代碼的“智能合約”，經(jīng)過一系列的操作之后，控制區(qū)塊鏈網(wǎng)絡(luò)中的所有節(jié)點，從而為所欲為。從The DAO到BEC，SMT，RMC，Ammbr（AMR），再到現(xiàn)在的OPL。

之前就有說過，發(fā)現(xiàn)OnPlace (OPL) Token 合約中存在整數(shù)溢出漏洞。該合約燒幣功能存在乘方運算可導(dǎo)整數(shù)溢出，通過精心構(gòu)造指數(shù)，使得燒幣的實際值為零（虛假燒幣）。

回顧到之前的溢出漏洞AMR：

據(jù)曲速未來安全區(qū)之前的披露：2018年6月29日，香港最大的數(shù)字貨幣交易所Coinsuper（幣成）全球首發(fā)了Ammbr（AMR）。之后被監(jiān)控到AMR合約存在高危安全風(fēng)險的交易。通過對代碼分析，發(fā)現(xiàn)其中存在重要安全溢出漏洞，報道時已經(jīng)被人惡意利用并且進(jìn)行大量增發(fā)。對此，曲速未來安全區(qū)也做出了提醒：智能合約需要進(jìn)行嚴(yán)格謹(jǐn)慎的安全評估才可以代表資產(chǎn)進(jìn)行交易，同時也請相關(guān)用戶注意數(shù)字資產(chǎn)安全。

漏洞說明：

這次漏洞是屬于一類通用問題，在之前已經(jīng)被爆出過，還將此漏洞命名為multiOverflow。此漏洞是由于整型溢出問題引起，最終會導(dǎo)致原交易發(fā)起人使用0個或者少量的幣就可以給其他地址轉(zhuǎn)入大量的代幣。

此漏洞是由于整型溢出問題引起，詳細(xì)缺陷代碼片段如下：

現(xiàn)在的這個OPL合約由乘?運算導(dǎo)致整數(shù)溢出，進(jìn)?引發(fā)虛假燒幣的安全漏洞。

OPL Token 目前并未上線交易所，但目前仍有較活躍的交易，疑似處于眾籌階段。

問題合約代碼 burnWithDecimals() 函數(shù)中 10 ** _dec 這?乘?操作存在整數(shù)溢出漏洞，可使計算結(jié)果為 0。若 _dec 傳?值?于 255，則最終 _value值會被更新為 0。

黑客可通過構(gòu)造攻擊參數(shù)，在自身余額并不減少的情況下，觸發(fā)燒幣 Burn() 事件。如果有 DApp 監(jiān)聽此事件并根據(jù)燃燒代幣的數(shù)值進(jìn)?下?步操作，?客則完成了虛假燒幣操作，后果將?分嚴(yán)重。對此，建議項???即廢棄該合約，并重新發(fā)布修復(fù)后合約。DApp 開發(fā)者和項??切勿信任此合約的燒幣 Burn() 事件。

特別提醒一下:開發(fā)者應(yīng)該提高自己的安全意識，由于乘?操作極易發(fā)?溢出，?常? SafeMath只涉及了加減乘除操作，開發(fā)者使?時應(yīng)當(dāng)慎之?慎。

事實上此合約還存在其他問題，如 burnWithDecimals() 中的乘法操作也沒有做整數(shù)溢出防護(hù)，emission() 函數(shù)也有類似問題。

區(qū)塊鏈安全檔案再次倡議：項??應(yīng)?刻采取措施，及時做好補(bǔ)救?作。還有項目方在發(fā)行Token時一定要慎之又慎，應(yīng)建立自己統(tǒng)一的安全標(biāo)準(zhǔn)，并對照安全標(biāo)準(zhǔn)嚴(yán)格執(zhí)行，進(jìn)行逐一檢查。遵守智能合約安全開發(fā)規(guī)范，引入安全審計流程，必要時請專業(yè)的智能合約審計公司，對合約代碼用形式化驗證的方法進(jìn)行審計，并由審計公司給出詳細(xì)的審計報告，確保萬無一失。

我們同時也請普通持幣?戶保持警惕，對不熟悉的代幣在購買時也要更為謹(jǐn)慎，選擇通過專業(yè)的代碼審計平臺審計過的代幣合約才能有效地保障自己的數(shù)字資產(chǎn)的安全，要做到防患于未然。