针对前段时间EOS漏洞问题，本文将进行整体细节的回顾，希望大家提起安全意识，但也不要过度恐慌，正确看待安全问题。

一、事件概述

6月22日凌晨，EOS官方社区发布消息称：发现EOS漏洞，用户抵押投票的代币在漏洞修复之前都无法赎回。随后我们根据相关消息对该漏洞进行验证确认该漏洞确实存在，且在漏洞修复前，通过精心构造的攻击使得特定用户资产进行无限期抵押，无法赎回。

我们知道EOS采用DPoS共识机制，该机制通过社区投票选举21个超级节点来维护EOS网络，为EOS网络提供算力、带宽以及存储支持。用户投票不需消耗EOS，但EOS会被锁定。用户可以随时申请赎回抵押的EOS，申请赎回后 72小时后到账，同时，投票将被扣减。

此次漏洞事件发生在EOS赎回过程中，如果其他用户抵押EOS给赎回用户，系统首先将赎回用户赎回过程中的EOS进行再次抵押。我们已经知道申请赎回的EOS需要72小时才能到账，如前所诉，通过精心构造的攻击理论上使得指定用户资产进行无限期抵押，对用户造成严重危害。

二、漏洞攻击流程

1.假设被攻击用户拥有0.0005个正在赎回途中EOS。

2.此时攻击者向赎回用户抵押0.0001个EOS。

3.交易生效后，我们看到攻击者的余额没有发生变化，而赎回用户正在赎回途中的0.0001个EOS被迫再次进行抵押。

三、漏洞原理解析

攻击流程图中的攻击命令如下：

cleos --wallet-url http://localhost:6666 --url http://mainnet.genereos.io:80 system delegatebw (attacker) (victim) "0.0001 EOS" "0.0000 EOS" --transfer

由于攻击者在调用命令时加入了--transfer参数，在调用到抵押函数delegatebw时会调用changbw函数，此时transfer为true

当transfer变量为true时，from地址变成被攻击对象的地址，

接下来被攻击对象的数据被修改，EOS再次抵押，

四、漏洞缓解方案

综合以上分析，本文建议修改部分业务逻辑缓解和修复该抵押漏洞。

1.transfer参数不管是否为true，都应该直接在抵押发起方余额中扣除（赎回过程不受此限制）；

2.梳理相关业务逻辑，审查是否存在类似漏洞。

五、漏洞分析总结

通过以上分析，通过精心构造的攻击使得特定用户资产进行无限期抵押，无法赎回。利用缓解方案的措施修补代码能够有效缓解和修复该漏洞。