本文章由火币区块链研究院出品，本报告发布时间2018年5月31日，作者：袁煜明，胡智威，李慧
2018年5月29日，360公布了其发现EOSIO严重漏洞的消息。此新闻及后续一系列相关跟进事件迅速成为区块链领域内的舆论热点。随着越来越多的声音与内容出现，各界对此次事件也逐渐有了更为清晰的认识。在此有必要从技术角度对此次事件进行客观复盘与分析，并再次对区块链安全进行探讨。
1. 事件回顾
根据目前网上公开资料，包括博客、代码记录等，我们对本次安全事件的技术过程进行一个简要梳理：
北京时间5月28日 360公司Vulcan（伏尔甘）团队联系主导EOSIO开发的Daniel Larimer（即bytemaster，以下简称BM）并报告了发现的高危安全漏洞情况
5月28日 BM在github的eos项目上新建了一个需要跟踪的问题（Issue）。同天，该问题所描述的bug被修复；该问题关闭
5月29日中午，360公司在其官方微信公众号上公布了区块链平台EOSIO的高危安全漏洞的消息
同天晚些时候，360公司在其公司博客“奇虎360技术博客”上公布了该漏洞的细节内容
2. 技术分析
我们首先从奇虎360技术博客的报告“EOS节点远程代码执行漏洞 — EOS智能合约WASM函数表数组越界”（http://blogs.360.cn/blog/eos%E8%8A%82%E7%82%B9%E8%BF%9C%E7%A8%8B%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C%E6%BC%8F%E6%B4%9E/ ）中来查看本次漏洞的详细技术内容。
根据报告所述，在修复该漏洞的提交ea89dce21d13d41a22b3512a27be97b4be9df755之前的代码版本上，我们可以看到在libraries/chain/webassembly/binaryen.cpp文件的76行，有assert用于检查变量取值情况。但assert一般仅适用于程序编译构建的Debug模式，对于正式发布的Release模式通常并不起作用，因此相当于没有做检查，导致78行对数组的访问存在隐患。
因此在发现该漏洞后，开发团队已将assert改为可正常调用的名为FC_ASSERT的宏定义。
知道了问题所在后，我们再来看一下编写EOSIO所使用的C++程序的内存结构及语言特性。
C++程序的内存区域包括栈区、堆区、自由存储区、静态全局存储区、常量区及代码区等。每个区域均有其独特的作用。同时，C/C++允许程序员通过指针等方式，对内存进行极为自主的控制及使用，并不强制检查数组边界等条件。因为包括内存管理在内的种种极为灵活、可控制底层的语言特性，C/C++凭借其高性能被广泛使用于对程序执行速度有严格要求的工业界。但也正是因为这种灵活性，C/C++程序常会因为内存管理的复杂性而出现内存泄露、宕机或内存越界等问题。这点在大型工程上尤其常见。
原因在于，C++程序指针访问到相应内存区域，即有可能对其进行相应的操作，所以如果控制不当，访问到原本的“界限”之外，就会产生越界的问题：如果访问到数据区域，则可能会引起程序崩溃或读取、修改到原本不应访问到的信息；如果访问到代码区域，则可能注入或改变原有正常代码。这就是缓冲区溢出的基本原理。
作为计算机及互联网上十分常见且潜在影响巨大的攻击手段，利用缓冲区溢出进行攻击有记录的最早一次是发生在1988年的Morris蠕虫攻击。据估计，它一经出现便影响了互联网上10%的计算机，造成约10万至100万美元的损失。从其首次出现到今天的30年间，很多著名的攻击事件都采取了缓冲区溢出的方式进行，其影响也随着互联网的发展而扩大。
回到本次EOSIO的这个漏洞，根据360的报告我们可以看到：当检查代码失效后，如果offset变量被任意设置一个地址，例如0xfffffff，则会引起segmentation fault的错误而导致程序崩溃；而如果对合约进行精心设计，攻击者可通过对内存越界写入的方式来执行恶意代码，正如360报告中附加的视频所示。
同时，如果能将风险控制在单机范围内，那对全局来说影响还是相对可接受的。但正是由于恶意代码可以是一个区块链上的合约，因此EOSIO将合约打包成区块后会在整个网络中传播，使得所有节点均可被此恶意代码控制，即整个网络都受到致命影响。
3. 构建区块链安全生态
从本次漏洞结合近期以太坊ERC20漏洞等安全事件，我们应更加认识到《【火线视点3】从ERC20漏洞事件看区块链安全生态建设》中的观点：区块链安全生态不仅仅需要项目团队、开发人员，更需要多方的通力合作。下面主要从项目团队内控、项目生态激励和投资者自我防范这三个方面去探讨区块链安全生态的建设。
3.1. 完善代码安全审查机制
回顾ERC20漏洞事件和EOSIO的缓冲区溢出事件，他们完全都可以通过有效的代码安全审查机制来避免。以ERC20漏洞为例，经过核查，使用ERC20协议的项目竟然有20余个都存在类似的问题。
瞬息万变的币圈确实发展的太快，每一个人都是飞奔着前进，都赶着写白皮书、赶着募资、赶着上项目，自然而然就很少有人沉下心来好好做测试，好好做安全审查，导致漏洞频出、安全事件频发。
区块链作为一个分布式的去中心化系统，代码一旦部署将很难更新，需通过硬分叉或者软分叉来对代码进行升级，成本不可谓不高。THE DAO事件则直接将以太坊分裂成为ETH和ETC，是对以太坊生态的重大破坏。所以在项目发布之前，充足的测试和代码审核变得十分关键和必要。比如多人代码审核、内部测评小组、外部专家评测等。
1）多人代码审核
由于一个人的能力和认知总是有限的，所以对于同一段代码，不同的人将会发现不同的问题，多人代码审核机制能使得代码的BUG率和漏洞率大大降低。这种方式也是软件行业降低错误率最为通用和有效的方式之一。
2）内部测评小组
项目组建立内部安全测评小组，梳理业界常见的安全问题清单，并逐一对发布的项目进行安全审计，通过简单的梳理和测评便能将常见的基本漏洞一扫而空，大大增加了系统的可靠性。
3）外部专家评测
对于某些新型的，特殊性的漏洞，项目组可以借助于例如第三方评测机构等外部安全专家的帮助进行梳理和测评，争取在项目发布前将安全隐患降到最低程度。
3.2. 发展白帽黑客激励机制
世界无非两极，一阴一阳、一黑一白、一正一邪，有黑客肆意破坏，就有白帽黑客维护世界正义。随着各类数字资产的市值越来越高，黑客们从中套取的收益也越来越客观，相比之下，白帽黑客们却穷酸的多。这种巨大的收入差导致越来越多人加入的黑客的阵营，而白帽黑客们则为数稀少。通过激励白帽黑客来抑制或者是平衡黑客越来越肆无忌惮的破坏行为或许将成为一种有效的手段。
那么如何激励白帽黑客们为平台做出贡献呢？我想主要可以从两方面入手，一是物质激励，二是精神激励。
1）物质激励
对于发行通证的公链来说，最实在的物质激励自然就是通证。它既是区块链平台的价值载体，也是平台生态治理的重要手段。比如COSMOS，为了鼓励发现并及时报告缺陷，Cosmos Hub允许黑客通过ReportHackTx 交易来“邀功”，主要就是说明，“这个节点已被攻击，请将奖金发到这个地址”。黑客可以收到击中资产的5%作为赏金。
除此之外我们也可以通过设立黑客奖金池、黑客基金或者项目特别顾问等方式来激励白帽黑客主动挖掘漏洞，帮助平台持久安全地运行。
2）精神激励
除了物质奖励，对于Hacker这一非常另类、有性格的群体来说，精神上的激励或许是更持久有效的方式。对于每一个为平台或者项目作出贡献的黑客来说，项目组、基金会或者社区都应将给与其相应的荣誉奖励。可以是排行榜、贡献值亦或是某种稀缺头衔等等，使其不仅能被社区其它成员知晓，更能明显区别于普通会员，增强其在社区的存在感、参与感和荣誉感。更可考虑用较为“极客”的方式进行精神激励，例如将白帽黑客对平台、社区的贡献记录在区块链上，形成更有针对性的生态系统良性循环。
火币区块链应用研究院
关于我们：
火币区块链应用研究院（简称“火币研究院”）成立于2016年4月，于2018年3月起全面拓展区块链各领域的研究与探索，主要研究内容包括区块链领域的技术研究、行业分析、应用创新、模式探索等。我们希望搭建涵盖区块链完整产业链的研究平台，为区块链产业人士提供坚实的理论基础与趋势判断，推动整个区块链行业的发展。
火线视点是火币研究院推出的区块链市场热点类研究报告。该系列聚焦区块链行业最新热点新闻事件、热门话题事件，以专业、客观的视角解读事件的本质，为广大读者提供及时且通俗易懂的分析。
联系我们：
咨询邮箱：[email protected]
公众号：火币区块链研究院
Twitter:Huobi_Research
Medium:Huobi Research
Facebook:Huobi Research
免责声明：
1、火币区块链研究院与本报告中所涉及的数字资产或其他第三方不存在任何影响报告客观性、独立性、公正性的关联关系。
2、本报告所引用的资料及数据均来自合规渠道，资料及数据的出处皆被火币区块链研究院认为可靠，且已对其真实性、准确性及完整性进行了必要的核查，但火币区块链研究院不对其真实性、准确性或完整性做出任何保证。
3、报告的内容仅供参考，报告中的事实和观点不构成相关数字资产的任何投资建议。火币区块链研究院不对因使用本报告内容而导致的损失承担任何责任，除非法律法规有明确规定。读者不应仅依据本报告作出投资决策，也不应依据本报告丧失独立判断的能力。
4、本报告所载资料、意见及推测仅反映研究人员于定稿本报告当日的判断，未来基于行业变化和数据信息的更新，存在观点与判断更新的可能性。
5、本报告版权仅为火币区块链研究院所有，如需引用本报告内容，请注明出处。如需大幅引用请事先告知，并在允许的范围内使用。在任何情况下不得对本报告进行任何有悖原意的引用、删节和修改。