AdamSzymanski - Insufficient Reentrancy Protection in ripcord Function Due to Reliance on onlyEOA Modifier

[sherlock-admin4]

AdamSzymanski

Medium

Insufficient Reentrancy Protection in ripcord Function Due to Reliance on onlyEOA Modifier

Summary

Very similar issue as in this Sherlock report

The ripcord function in the MorphoLeverageStrategyExtension contract relies on the onlyEOA modifier to restrict access to externally owned accounts (EOAs). However, this check is insufficient as a reentrancy guard. Without proper reentrancy protection, the function is vulnerable to reentrancy attacks, which could lead to unintended state changes or financial loss.

Root Cause

The contract uses the onlyEOA modifier, which checks msg.sender == tx.origin, to ensure that only EOAs can call the ripcord function. This approach is not a substitute for a reentrancy guard because it does not prevent contracts from re-entering functions during execution. Additionally, future Ethereum proposals like EIP-3074 could allow contracts to impersonate EOAs, rendering the onlyEOA check ineffective.

Code Location

• File: MorphoLeverageStrategyExtension.sol
• Function: ripcord

modifier onlyEOA() {
    require(msg.sender == tx.origin, "Must be EOA address");
    _;
}

function ripcord(string memory _exchangeName) external onlyEOA {
    // Function logic...
    uint256 etherTransferred = _transferEtherRewardToCaller(incentive.etherReward);
    //...
}

Internal Pre-conditions

• The contract holds an Ether balance sufficient to pay the incentive reward.
• The ripcord function is callable and intended to be used during high leverage situations.

External Pre-conditions

• An attacker can deploy a malicious contract designed to exploit reentrancy.
• The attacker is motivated to drain the contract's Ether balance or manipulate its state.

Attack Path

1. Preparation: The attacker deploys a malicious contract capable of re-entering the ripcord function.
2. Invocation: The attacker calls the ripcord function via their malicious contract.
3. Reentrancy: During the Ether transfer in _transferEtherRewardToCaller, the attacker re-enters the ripcord function.
4. Exploitation: The attacker repeats this process to drain Ether rewards or manipulate the contract state.

Impact

• Financial Loss: The attacker can drain the Ether balance allocated for rewards.
• State Manipulation: Unintended changes to leverage positions or other sensitive state variables.
• Contract Disruption: The contract may behave unpredictably or enter an invalid state.

Estimated Loss

The attacker could potentially drain all Ether allocated for incentives. The exact amount depends on the contract's Ether balance but could be significant.

Mitigation

• Implement Reentrancy Guard: Use a reentrancy guard, such as OpenZeppelin's ReentrancyGuard, to prevent reentrancy attacks.

  import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
  
  contract MorphoLeverageStrategyExtension is BaseExtension, ReentrancyGuard {
      //...
  
      function ripcord(string memory _exchangeName) external nonReentrant onlyEOA {
          // Function logic...
      }
  }

• Avoid Reliance on onlyEOA: Do not rely solely on onlyEOA for security-critical functions.

Conclusion

The reliance on the onlyEOA modifier in the ripcord function is insufficient for reentrancy protection. Implementing proper reentrancy guards ensures the function is secure against reentrancy attacks, both now and in the future, even if Ethereum's capabilities evolve.