2018年7月12日匪煌，成都鏈安科技（LianAn Technology）智能合約審計小組使用自主研發(fā)的VaaS平臺對以太坊鏈上智能合約進行安全審計的過程中榴徐，發(fā)現(xiàn)了3份合約存在新的安全漏洞膳灶。此漏洞是合約構(gòu)造函數(shù)constructor()使用不當從而導致Owner權(quán)限被盜嚎莉。
問題描述
以太坊solidity0.4.22引入了新的構(gòu)造函數(shù)聲明形式constructor()悯搔，該函數(shù)引入的目的是避免編程人員在編寫構(gòu)造函數(shù)時的命名錯誤 （如6月22日灾常，MorphToken事件中“Owned”被寫成“owned”照激，沒有注意大小寫发魄，使owned函數(shù)成為一個普通函數(shù)，導致任何賬戶都能調(diào)用它俩垃，更改owner變量励幼，轉(zhuǎn)移合約所有權(quán)）。
然而吆寨，由于用戶編寫函數(shù)時習慣性的使用function進行聲明赏淌，從而導致構(gòu)造函數(shù)constructor的使用引入新的漏洞。
正確的構(gòu)造函數(shù)形式：constructor() public { }
錯誤的構(gòu)造函數(shù)形式：function constructor() public { }
成都鏈安科技使用 VaaS平臺對以太坊區(qū)塊鏈上智能合約進行了分析啄清，發(fā)現(xiàn)如下3份智能合約存在constructor函數(shù)使用不當導致Owner權(quán)限被盜的問題六水。
3份合約地址如下，請項目方自查辣卒，或與我們?nèi)〉寐?lián)系：
對應(yīng)視頻：
https://v.qq.com/x/page/t1344wir41t.html
通過VaaS平臺的自動化工具檢測掷贾，準確定位到了錯誤代碼的位置，并高亮顯示荣茫。
問題分析：敏感函數(shù)使用不當
鏈安科技安全審計團隊發(fā)現(xiàn)想帅，上述問題合約使用的Solidity編譯器版本包含了0.4.15、0.4.23啡莉，而只有在Solidity0.4.22版本后港准，合約的constructor()函數(shù)才被視為構(gòu)造函數(shù)的形式，并且直到下一版本才會對function constructor()的形式給出警告（注意：這里僅僅是警告咧欣，不是錯誤）浅缸。如果是使用Solidity0.4.23之前的版本，編譯器把function constructor()作為普通函數(shù)進行編譯魄咕，認為是正確的普通函數(shù)衩椒。
鏈安科技智能合約安全審計團隊對存在該問題的合約進行了深入分析，由于該函數(shù)不符合構(gòu)造函數(shù)形式哮兰，所以以太坊平臺將把constructor函數(shù)作為普通函數(shù)供任何用戶進行調(diào)用毛萌。進一步， owned合約的function constructor()函數(shù)的功能是將創(chuàng)建者地址賦予給owner喝滞，用于后續(xù)的身份驗證阁将。因此，任意賬戶地址都可以調(diào)用constructor()函數(shù)囤躁，并修改owner的值冀痕，導致合約管理權(quán)限被盜用荔睹。
漏洞驗證
安全審計小組將問題合約在Ropsten測試鏈上對該問題進行了進一步驗證言蛇，發(fā)現(xiàn)：
1.由于缺少構(gòu)造函數(shù)僻他，初始化 owner值為0：
2.使用remix調(diào)用constructor函數(shù)，發(fā)現(xiàn)交易失敗腊尚，分析后發(fā)現(xiàn)data字段不是constructor的函數(shù)簽名：
3.更換另一個版本的solidity編譯器吨拗，執(zhí)行constructor函數(shù)，發(fā)現(xiàn)owner被更改婿斥，說明該漏洞存在：
Owner權(quán)限過大存在的安全隱患
Owner是Solidity語言中對智能合約開發(fā)者的稱呼劝篷，owner的能力猶如集齊6顆無限寶石的滅霸，屬于超級權(quán)限民宿。對前100基于以太坊ERC20協(xié)議智能合約（例如Bancor娇妓、Augur、MakerDAO活鹰、KyberNetwork哈恰、EnigmaMPC的智能合約）安全事件進行分析后，超級權(quán)限被盜可存在如下安全隱患：
?隨時凍結(jié)代幣轉(zhuǎn)賬
?任意鑄造發(fā)行新的代幣
?銷毀任意賬戶內(nèi)的代幣
?額外增發(fā)代幣
?停止整套交易系統(tǒng)運行
Owner權(quán)限如此之大志群，說明眾多“去中心化”的產(chǎn)品着绷，實際上暗藏一個一擊必殺按鈕，掌握在開發(fā)者的手上锌云，所有對代幣虎視眈眈的黑客或者內(nèi)部人員都會想方設(shè)法奪取這個按鈕的控制權(quán)荠医。
如此強大的權(quán)限一旦被黑客竊取，相當于從滅霸手上搶到了無限拳套桑涎，黑客可以對依賴智能合約交易的代幣為所欲為彬向，無論是凍結(jié)，增發(fā)攻冷，還是自毀幢泼，只需要調(diào)用合約中一個函數(shù)就可輕松實現(xiàn)，進而操縱整個代幣的價值讲衫。而與之相關(guān)的代幣也必將遭受沖擊，后果不堪設(shè)想孵班。
如何避免將會導致的風險
既然合約開發(fā)者可能會存在使用constructor函數(shù)不當涉兽，那么作為項目方應(yīng)該如何去防范后期可能造成的風險呢？我們給出下面兩種建議方法：
1.新的constructor使用方法為篙程，前面無function聲明：
2.Remix-ide等編譯器會對constructor的錯誤使用產(chǎn)生警告枷畏，開發(fā)者千萬不要忽略編譯器告警，推薦更改源碼虱饿，消除所有編譯器警告拥诡。
問題總結(jié)
鏈安科技團隊整合審計小組的驗證結(jié)果以及各區(qū)塊鏈安全專家的意見后指出該漏洞導致的后果可能有：
1.合約可被普通用戶竊取owner權(quán)限触趴；
2.目前很多ERC20代幣部署的時候?qū)⑺写鷰虐l(fā)放到owner賬戶中，如果出現(xiàn)此漏洞渴肉，可導致用戶無限增發(fā)代幣冗懦；
以及更多取決于owner權(quán)限的嚴重后果（也許就像滅霸打一個響指，代幣灰飛煙滅仇祭？）披蕉。
此次owner權(quán)限漏洞雖然來源于代碼編寫上的低級錯誤，但更多的是引起開發(fā)者對owner權(quán)限問題的反思乌奇，過于神化的owner權(quán)限必然導致owner權(quán)限漏洞成為眾矢之的没讲，而低級錯誤導致的此類漏洞是絕不應(yīng)該出現(xiàn)的。
項目方及開發(fā)者應(yīng)引起足夠重視
因此礁苗，鏈安科技團隊強烈呼吁廣大開發(fā)者在合約編寫上遵守開發(fā)規(guī)范爬凑，并且在寫合約敏感函數(shù)（如構(gòu)造函數(shù)、回調(diào)函數(shù)）時试伙，應(yīng)嚴格遵循官方命名要求嘁信，同時千萬不要忽略編譯器告警，在合約發(fā)布到主鏈之前迁霎，應(yīng)在官方提供的測試網(wǎng)站上進行充分驗證吱抚。必要的時候采用形式化驗證手段，從多角度分析合約代碼考廉，找出那些容易忽略的問題秘豹，并且做到防患于未然。
同時昌粤，項目方在合約編寫完成后既绕，應(yīng)當尋求有質(zhì)量保證的智能合約安全審計團隊進行合約安全審查，保證合約的安全性和功能準確性涮坐，防患于未然凄贩。
「成都鏈安科技」
作為火幣網(wǎng)、OKex袱讹、KuCoin等著名交易所指定的合約審計公司疲扎。 歡迎聯(lián)系鏈安，進行智能合約安全審計捷雕。本文原始鏈接
