EgisSecurity - Blockchain reorgs may result in locked funds for the victim

[sherlock-admin4]

EgisSecurity

Medium

Blockchain reorgs may result in locked funds for the victim

Summary

SuperPoolFactory#deploySuperPool is vulnerable to reorg attack issues, because it uses create opcode. This opcode uses only the deployer address + deployer address nonce (count of deployed contract) to calculate the address of the new SuperPool, which is being deployed. In the contest README it is written that compatible chains are all EVM chains. We assume Mainnet and Polygon are valid chains for this scope, as those are the chains with the most frequent and deep reorganizations.

Root Cause

Using create when deploying SuperPool from SuperPoolFactory

Internal pre-conditions

• Someone is calling SuperPoolFactory#deploySuperPool
• Someone (maybe depositor) deposits to the address, which is returned from the above operation
• Expoiter should have victim's funds + 2%

External pre-conditions

• Blockchain reorg event is happening, which includes victims SuperPoolFactory#deploySuperPool transaction

Attack Path

Imagine the following scenario:

1. Victim wants to create a SuperPool for WETH and calls SuperPoolFactory#deploySuperPool and that operation returns firstSuperAddress
2. Victim calls firstSuperAddress.deposit with amount of 10 WETH
3. Victim starts to add base pools to his super pool.
4. Reorg is happening
5. The Expoiter bot detects the event and here is the order of his actions:
   • Expoiter manages to put a new SuperPoolFactory#deploySuperPool, which will be before the victim's transaction after the reorg, which will result in firstSuperAddress, but with the exploiter as owner/modifier of the pool.
   • Victim deploy and deposit transactions hit execution with the new blockchain state, but his deployed SuperPool is on another address, while deposit transaction is still using firstSuperAddress
   • Exploiter creates new base pool with the cheapest rate model and WETH as lending and some other asset for collateral with 98% ltv.
   • He fills collateral for his position, adds base pool to the firstSuperAddress and calls SuperPool#reallocate with the base pool that he has just created and all 10 WETH of the victim.
   • Malicious actor instantly borrows those 10 WETH and pause the base pool

• Now the victim is unable to withdraw his funds and they may accrue neglectable interest because exploiter will use the most cheap rate model
• Expoiter may blackmail the victim to send him % of the locked funds, so he can repay the debt and send him back the funds

Impact

• Locked funds for victim
• Exploiter may long/short the victim's fund and benefit from that

PoC

No response

Mitigation

Use create2 while deploying the super pools and use owner's address for the salt.

Duplicate of #115

[sherlock-admin2]

1 comment(s) were left on this issue during the judging contest.

z3s commented:

invalid due to sherlock rules and criteria not being met. Chain re-org and network liveness related issues are not considered valid. Exception: If an issue concerns any kind of a network admin (e.g. a sequencer), can be remedied by a smart contract modification, the protocol team considers external admins restricted and the considered network was explicitly mentioned in the contest README, it may be a valid medium. It should be assumed that any such network issues will be resolved within 7 days, if that may be possible.