复盘 EOS 安全事件，再议区块链安全的重要性

本文章由火币区块链研究院出品，本报告发布时间 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 函数表数组越界” 中来查看本次漏洞的详细技术内容。

根据报告所述，在修复该漏洞的提交 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 这一非常另类、有性格的群体来说，精神上的激励或许是更持久有效的方式。对于每一个为平台或者项目作出贡献的黑客来说，项目组、基金会或者社区都应将给与其相应的荣誉奖励。可以是排行榜、贡献值亦或是某种稀缺头衔等等，使其不仅能被社区其它成员知晓，更能明显区别于普通会员，增强其在社区的存在感、参与感和荣誉感。更可考虑用较为“极客”的方式进行精神激励，例如将白帽黑客对平台、社区的贡献记录在区块链上，形成更有针对性的生态系统良性循环。

来源链接：www.jianshu.com

—-

编译者/作者：袁煜明

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。