Ultrain发现并协助修复EOS致命漏洞并获官方致谢！

Ultrain技术团队核心成员近期在阅读EOS chainbase开源代码时，发现其底层实现存在可导致EOS全网宕机隐患的致命安全漏洞，并立即将问题详细描述及修复办法提交至EOS团队。近日，EOS团队已正式将修复提交EOS代码主分支，并对于Ultrain @raymondnuaa表示多次致谢！

EOS采用chainbase内存数据库存储世界状态，包括链上所有账号详情、部署的所有智能合约以及所有历史交易形成的状态修改等内容。chainbase的安全性与稳定性是保证EOS稳定运行的重中之重。

EOS该安全漏洞由chainbase对数据库回滚操作的错误处理顺序引发。chainbase内存数据库底层有removed、created、modified三个stack来存储区块内交易对数据库对象所进行的删除、创建、修改操作，如果该区块未能成功添加到区块链主链，则需要对该区块内所有交易对内存数据库做的所有修改进行回滚。

EOS对三个stack的原有回滚处理顺序为：modified，created，removed，在该处理顺序下，如果将数据库某个已有对象A的键值修改，并创建一个新的对象B采用前述对象A的原有键值，那么在进行回滚时，会先尝试将对象A修改过的数值恢复，此时会产生键值冲突（数据库此时存在对象B具有相同键值），导致底层库进入死循环状态。一旦进入该状态，EOS节点则无法正常继续生产区块。若恶意攻击者构造触发该状态的交易广播至全网执行(e.g.通过deferred trx)，则EOS全网存在宕机隐患。

发现问题后，EOS开发团队按 @raymondnuaa 建议将stack处理顺序修改为created，modified，removed，可正常处理前述场景。此外，@raymondnuaa 在问题描述中还详细描述了另一个更加复杂的两个对象键值交换的场景，并指出仅靠调整三个stack的处理顺序无法解决问题。EOS在此次修改中也增加了大量注释，明确了chainbase内对象的使用需求限制，指出chainbase的特定字段不能在modifier 中进行修改(should not be changed withina chainbase modifier lambda)，并对deferred_transaction的modify处理做了相应修改。

Ultrain愿与业内同行一起，共同提升基础设施安全，促进行业健康有序发展。

#详情链接#

https://github.com/EOSIO/eos/pull/7266

https://github.com/EOSIO/chainbase/pull/44