Skip to content

Latest commit

 

History

History
52 lines (32 loc) · 1.59 KB

040.md

File metadata and controls

52 lines (32 loc) · 1.59 KB

Fast Khaki Raccoon

Medium

Protocol assumes the same deployment on all chains on multiple occasions

Summary

Protocol assumes the same deployment on all chains on multiple occasions

Root Cause

In some contracts such as Zapper, we have a similar code such as the below:

contract Zapper is IZapper, Context, Ownable {
    using SafeERC20 for IERC20;

    address constant STYETH = 0x583019fF0f430721aDa9cfb4fac8F06cA104d0B4;
    address constant YETH = 0x1BED97CBC3c24A4fb5C069C6E311a967386131f7;
    address constant WETH_YETH_POOL = 0x69ACcb968B19a53790f43e57558F5E443A91aF22;
    address constant V3_ROUTER = 0xE592427A0AEce92De3Edee1F18E0157C05861564;
    ...
}

The protocol will be deployed on multiple different chains, thus we can not assume the same address on all of them, let's for example see the address of the YETH variable on Mode: https://modescan.io/address/0x1BED97CBC3c24A4fb5C069C6E311a967386131f7. As seen, it is a random EOA.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

2 paths:

  • a simple revert
  • contract matches the address and signature which can be abused and can lead to a theft of funds (especially if the contract is upgradeable). Furthermore, as Berachain is not deployed yet, a malicious user can deploy an address at the hardcoded addresses and abuse it that way

Impact

2 possible impacts - either reverts or if the address is a contract matching the function signatures, then this can lead to impacts such as a protocol drain.

PoC

No response

Mitigation

Do not hardcode the addresses