免责声明: 金色财经作为开放的资讯分享平台,所提供的所有资讯仅代表作者个人观点,与金色财经平台立场无关,且不构成任何投资理财建议。

一次由存储状态引发的惨案 Cover协议被黑简要分析

By :  Kong@慢雾安全团队

据慢雾区情报,2020 年 12 月 29 日,Cover 协议价格暴跌。慢雾安全团队第一时间跟进相关事件并进行分析,以下为分析简略过程。

攻击流程简析

1、在 Cover 协议的 Blacksmith 合约中,用户可以通过 deposit 函数抵押 BPT 代币;

2、攻击者在第一次进行 deposit - withdraw 后将通过 updatePool 函数来更新池子,并使用 accRewardsPerToken 来记录累计奖励;

3、之后将通过 _claimCoverRewards 函数来分配奖励并使用 rewardWriteoff 参数进行记录;

4、在攻击者第一次 withdraw 后还留有一小部分的 BPT 进行抵押;

5、此时攻击者将第二次进行 deposit,并通过 claimRewards 提取奖励;

6、问题出在 rewardWriteoff 的具体计算,在攻击者第二次进行 deposit - claimRewards 时取的 Pool 值定义为 memory,此时 memory 中获取的 Pool 是攻击者第一次 withdraw 进行 updatePool 时更新的值;

7、由于 memory 中获取的 Pool 值是旧的,其对应记录的 accRewardsPerToken 也是旧的会赋值到miner;

8、之后再进行新的一次 updatePool 时,由于攻击者在第一次进行 withdraw 后池子中的 lpTotal 已经变小,所以最后获得的 accRewardsPerToken 将变大;

9、此时攻击者被赋值的 accRewardsPerToken 是旧的是一个较小值,在进行 rewardWriteoff 计算时获得的值也将偏小,但攻击者在进行 claimRewards 时用的却是池子更新后的 accRewardsPerToken 值;

10、因此在进行具体奖励计算时由于这个新旧参数之前差值,会导致计算出一个偏大的数值;

11、所以最后在根据计算结果给攻击者铸造奖励时就会额外铸造出更多的 COVER 代币,导致 COVER 代币增发。

具体 accRewardsPerToken 参数差值变化如下图:

jinse.com
好文章,需要你的鼓励
jinse.com
好文章,需要你的鼓励
了解更多区块链一线报道,与作者、读者更深入探讨、交流,欢迎添加小助手微信:jinsecaijing666, 进入[金色财经读者交流群]。
发表评论
0/140
发布评论
评论
文章作者: / 责任编辑: 我要纠错

声明:本文由入驻金色财经的作者撰写,观点仅代表作者本人,绝不代表金色财经赞同其观点或证实其描述。

提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。

金色财经 > 区块链 > 一次由存储状态引发的惨案 Cover协议被黑简要分析