Inheritable Smart Contract Wallet

Summary

The contractInteractions function allows the owner to perform arbitrary external calls, but due to its reliance on a flawed nonReentrant modifier, it becomes vulnerable to reentrancy if the owner calls a malicious contract.

Vulnerability Details

This function executes an external call:

While the function is protected by the nonReentrant modifier, that guard is implemented using transient storage and mistakenly checks a different slot (slot 1) than the one it writes to (slot 0). Consequently, the reentrancy guard may fail, allowing a malicious contract, when invoked by the owner, to perform reentrant calls into this contract.

Impact

• Exploitation Risk: An attacker controlling the target contract could re-enter vulnerable functions if the owner inadvertently interacts with a malicious contract.

• State Manipulation: Reentrancy could lead to unauthorized state changes or fund drainage in parts of the contract assumed to be secure.

• Increased Attack Surface: The broken guard undermines the security assumptions of the contract, leaving it open to subtle, complex attack vectors in multi-call transactions.

Tools Used

• Manual Code Review

1. Correct the Reentrancy Guard: Fix the nonReentrant modifier to use the same transient storage slot for both checking and setting the flag:

   modifier nonReentrant() {

   assembly {

   if tload(0) { revert(0, 0) }

   tstore(0, 1)

   }

   _;

   assembly {

   tstore(0, 0)

   }

   }

   ​

2. Use Established Libraries: Consider using a well-audited reentrancy guard from libraries such as OpenZeppelin.

3. Thorough Testing: Conduct comprehensive testing for reentrancy attacks, particularly when making arbitrary external calls.

4. Review External Interactions: Minimize risks by validating target contracts and carefully managing external calls, especially when involving complex transactions.