Cross Contract Reentrancy
Cross-contract reentrancy can happen when a state from one smart contract is used in another contract, but that state is not fully updated before getting called.
The conditions required for the cross-contract reentrancy to be possible are as follows:
- The execution flow can be controlled by the attacker to manipulate the contract state.
- The value of the state in the contract is shared or used in another contract.
Past cases of attacks
This kind of vulnerability has been used in multiple past attacks, for example:
Solutions to Prevent Reentrancy
For the first two variations, Single Function Reentrancy and Cross Function Reentrancy, a mutex lock can be implemented in the contract to prevent the functions in the same contract from being called repeatedly, thus, preventing reentrancy. A widely used method to implement the lock is inheriting OpenZeppelin’s ReentrancyGuard and use the nonReentrant modifier.
The better solution is to check and try updating all states before calling for external contracts, or the so-called “Checks-Effects-Interactions” pattern. This way, even when a reentrant calling is initiated, no impact can be made since all states have finished updating.
Another alternative choice is to prevent the attacker from taking over the control flow of the contract. A set of whitelisted addresses can prevent the attacker from injecting unknown malicious contracts into the contract in this lab.
Nevertheless, the contracts that integrate with other contracts, especially when the states are shared, should be checked in detail to make sure that the states used are correct and cannot be manipulated.
Sources
https://inspexco.medium.com/cross-contract-reentrancy-attack-402d27a02a15