Alchemix Transmuter

Description

Some ERC20 tokens may implement hooks that trigger external calls during transfers (e.g., ERC777 tokens or tokens with callbacks). If the strategy interacts with such tokens, it could be vulnerable to reentrancy attacks, especially in functions that make external calls after transferring tokens.

Although the StrategyOp contract uses ReentrancyGuard from OpenZeppelin, not all functions are protected, and reliance on the tokens conforming strictly to ERC20 standards without such behaviors may expose the contract to risks.

Impact

• Reentrancy Attacks: Malicious tokens could exploit reentrancy to re-enter functions and manipulate the contract's state, potentially draining funds.

• Security Vulnerabilities: Unprotected functions could be susceptible to attack vectors not considered in the original design.

Proof of Concept (PoC)

1. Scenario:

   • The asset or underlying token is an ERC777 token with a tokensReceived hook.

   • During a transfer, the token calls back into the strategy contract.

2. Outcome:

   • If the strategy function being re-entered is not protected, the attacker could manipulate internal balances or perform unauthorized actions.

Recommendations

• Implement Reentrancy Guards on Vulnerable Functions:

  • Use nonReentrant modifiers on functions that involve token transfers and external calls.

    function claimAndSwap(

    uint256 _amountClaim,

    uint256 _minOut,

    IVeloRouter.route[] calldata _path

    ) external onlyKeepers nonReentrant {

    // Function body

    }

• Assume Tokens May Have Callbacks:

  • Design contract logic with the assumption that tokens could have callbacks, avoiding modifying state variables after token transfers where possible.