EOSCUBE魔方节点首席技术架构师Jeffrey为你详解360发现EOS的“史诗级”漏洞

EOS主网上线越来越临近，国内著名安全软件360安全卫士发布长文表示发现EOS代码出现“史诗级大漏洞”，可以瞬间掌控所有的EOS节点交易。消息一出，业界哗然，使得很多人惶恐不安！EOS团队首先站出来表示此漏洞在360公布之时已经解决了，指360是在制造恐慌。

今天，柚子魔方eoscube节点首席技术架构师Jeffrey就此事进行了观点分享，下面是分享原文：

大家好，我是柚子魔方eoscube节点的首席技术架构师Jeffrey。今天很高兴在EOS121-DAC技术的私享会分享360发现EOS代码的“史诗级大漏洞”。

        360发现了这个EOS漏洞是典型的缓冲区溢出的漏洞。这种漏洞的容易造成缓冲区溢出的攻击。其中的攻击方式呢大家应该也在网上见过就是可能目前会存在五种攻击方式。这个漏洞就是会产生第三种攻击方式，就是可能也会有人通过这个缓冲区溢出漏洞，然后往这个EOS节点注入恶意代码，然后恶意代码和数据同时溢出的时候，他执行这个恶意代码的话，那可能就会导致这个EOS节点直接down机或者是那个继续污染其他的节点。

大家看一下这段代码，他很明显就是在offset与segment.data.size相加，判断这个溢出的时候出了问题，因为offset的字节的大小，可能是从0到1024字节，然后判断offset与segment.data.size相加的时候，table的边界却是32位。去判断assert的时候，用在这里并没有用错，因为当那个C++开发的时候，然后他会从那个debug模式使用这个assert去判断，但是发布出来之后，这个debug模式就肯定不会开启了。

assert是c语言中用的比较多的断言宏或函数，只有debug标志打开时才会起作用

所以呢，而assert一般是用来检查编程错误的，而不是程序运行的时候去捕捉错误的。所以这个应该是EOS开发的一个疏忽，但是因为EOS使用了一个第三方的库。这个不能怪EOS，只能说他们的这个开发人员他们没有去审核好这个第三方代码库。所以呢，他们就及时添加了FC_ASSERT这个函数进行修补。

其实这个错误是一个比较常见的错误，尤其在C++里面也是一个低级的错误，冯罗伊曼的计算机结构数据和代码放在同一个内存地址空间里面，当没有判断好指针数组和结构体边界的时候，然后这个栈执行，如果说这个溢出了，在这个时候我去注入恶意代码的话，这个栈就会执行这段恶意代码。然后这个判断就失效了。

这是虽然是一个比较简单的错误，但是其实这个错误对于EOS其实还是很致命的，因为它被执行之后，当它被打包到区块里面，然后让下一个节点进行验证。那下节点也会去执行这段代码。然后就会整个EOS网络直接被干掉了。

       EOS的代码直接fork的第三方的库，binaryen，这个库本身不算有错误，因为debug模式下就可以用，但是你发布正式版本的时候，应该把这个判断根据自己指针、数据的实际情况重写。因为我们开发c++的时候，必须要自己检查数组边界的，因为c++不检查，比如说以太坊geth，就不会出现这个问题，因为go运行时会检查边界。所以这是c++程序员的一个低级错误，估计eos迟迟没有公开也是怕别人笑话：-)

        现在是eos主网上线前发现的问题其实是好事，我相信他们会通过这一次事件好好审查代码的，本身eos的主要功能已经开发完了，官方一直在说上线前的主要任务是审查bug。