智能合约安全——delegatecall (1)

  • fingernft
  • 更新于 2022-08-02 15:11
  • 阅读 2027

在之前的内容中,学习到了storage中是使用插槽存储数据的。而delegatecall函数有个有趣的特点:当使用 delegatecall 函数进行外部调用涉及到 storage 变量的修改时是根据插槽位置来修改的而不是变量名。

在之前的内容中,学习到了storage中是使用插槽存储数据的。而delegatecall函数有个有趣的特点:当使用 delegatecall 函数进行外部调用涉及到 storage 变量的修改时是根据插槽位置来修改的而不是变量名。

举个例子: 合约A

图片1.png

合约B

图片2.png

当合约B调用testDelegatecall()函数时,合约B的地址c的值会变为合约A的地址,而地址a则是不变。因为合约A的函数test()改变的是插槽slot1的值,同样的在合约B中运行时,改变的也是插槽slot1的值,即地址c的值。

目标合约

图片3.png

漏洞分析

我们可以看到有两个合约,Lib 合约中只有一个 pwn 函数用来修改合约的 owner,在 HackMe 合约中存在 fallback 函数,fallback 函数的内容是使用 delegatecall 去调用 Lib 合约中的函数。我们需要利用 HackMe.fallback() 触发 delegatecall 函数去调用 Lib.pwn() 将 HackMe 合约中的 owner 改成自己。

攻击合约

图片4.png

现在我们来看看整个攻击的逻辑: 1.攻击者调用attack()发起攻击,attack 函数首先去调用 HackMe.pwn(); 2.HackMe 合约中并没有 pwn 函数,此时触发 HackMe.fallback(); 3.HackMe.fallback() 使用 deldegatecall 调用 Lib 合约中的函数,函数名取的是 msg.data 也就是 "pwn()",而 Lib 合约中恰好有名为 pwn 的函数,于是便在HackMe 合约中运行了pwn函数; 4.pwn函数修改了插槽slot0位置(即HackMe 合约的拥有者)的值为msg.sender(即攻击者),最终导致了HackMe 合约的拥有者变成了攻击者。 修复建议

  1. 在使用 delegatecall 时应注意被调用合约的地址不能是可控的;
  2. 在较为复杂的合约环境下需要注意变量的声明顺序以及存储位置。因为使用 delegatecall 进行外部调时会根据被调用合约的数据结构来用修改本合约相应 slot 中存储的数据,在数据结构发生变化时这可能会造成非预期的变量覆盖。

如果想了解更多的智能合约和区块链知识,欢迎到区块链交流社区CHAINPIP社区,一起交流学习~ 社区地址:https://www.chainpip.com/

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
fingernft
fingernft
github.com/fingerchar/fingernft 开源的NFT市场