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)系：

通過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)限被盜用霉翔。

image

注：msg.sender 為當前操作賬戶地址睁蕾、owner為合約管理者地址

漏洞驗證

安全審計小組將問題合約在Ropsten測試鏈上對該問題進行了進一步驗證，發(fā)現(xiàn)：

1.由于缺少構(gòu)造函數(shù)债朵，初始化 owner值為0：

image

2.使用remix調(diào)用constructor函數(shù)子眶，發(fā)現(xiàn)交易失敗，分析后發(fā)現(xiàn)data字段不是constructor的函數(shù)簽名：

image

3.更換另一個版本的solidity編譯器序芦，執(zhí)行constructor函數(shù)臭杰，發(fā)現(xiàn)owner被更改，說明該漏洞存在：

image

image

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)。

image

▲Dogecoin創(chuàng)始人Jackson Palmer的推特評論

如此強大的權(quán)限一旦被黑客竊取戚长，相當于從滅霸手上搶到了無限拳套盗冷，黑客可以對依賴智能合約交易的代幣為所欲為，無論是凍結(jié)同廉，增發(fā)仪糖，還是自毀，只需要調(diào)用合約中一個函數(shù)就可輕松實現(xiàn)迫肖，進而操縱整個代幣的價值锅劝。而與之相關(guān)的代幣也必將遭受沖擊，后果不堪設(shè)想蟆湖。

如何避免將會導致的風險

既然合約開發(fā)者可能會存在使用constructor函數(shù)不當故爵，那么作為項目方應該如何去防范后期可能造成的風險呢？我們給出下面兩種建議方法：

1.新的constructor使用方法為隅津，前面無function聲明：

image

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)限漏洞成為眾矢之的斤讥，而低級錯誤導致的此類漏洞是絕不應該出現(xiàn)的纱皆。

項目方及開發(fā)者應引起足夠重視

因此，鏈安科技團隊強烈呼吁廣大開發(fā)者在合約編寫上遵守開發(fā)規(guī)范芭商，并且在寫合約敏感函數(shù)（如構(gòu)造函數(shù)派草、回調(diào)函數(shù)）時，應嚴格遵循官方命名要求铛楣，同時千萬不要忽略編譯器告警近迁，在合約發(fā)布到主鏈之前，應在官方提供的測試網(wǎng)站上進行充分驗證簸州。必要的時候采用形式化驗證手段鉴竭，從多角度分析合約代碼歧譬，找出那些容易忽略的問題，并且做到防患于未然搏存。

同時瑰步，項目方在合約編寫完成后，應當尋求有質(zhì)量保證的智能合約安全審計團隊進行合約安全審查璧眠，保證合約的安全性和功能準確性缩焦，防患于未然。

本文轉(zhuǎn)載自《constructor函數(shù)使用漏洞》责静，版權(quán)屬于原作者袁滥，已獲得授權(quán)。