Open code423n4 opened 2 years ago
https://github.com/Rari-Capital/solmate/pull/174/files this is a known issue with 4626. xTRIBE would be initialized safely in this case
Known or unknown this is still a valid attack that isn't mitigated for in the current codebase. Given that there are mitigations that could be integrated on chain (like in the uniswap contracts that burn the first dust amount of LP tokens) , and the warden did demonstrate the attack I am going to downgrade this to medium severity as a "leak of value"
2 — Med: Assets not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements.
Lines of code
https://github.com/Rari-Capital/solmate/blob/12421e3edee21cfb99bf5a6edd6169e6497511de/src/mixins/ERC4626.sol#L133
Vulnerability details
Solmate
convertToShares
function follow the formula:assetDepositAmount * totalShareSupply / assetBalanceBeforeDeposit
.The share price always return 1:1 with asset token. If everything work normally, share price will slowly increase with time to 1:2 or 1:10 as more rewards coming in.
But right after xERC4626 contract creation, during first cycle, any user can deposit 1 share set
totalSupply = 1
. And transfer token to vault to inflatetotalAssets()
before rewards kick in. (Basically, pretend rewards themselves before anyone can deposit in to get much better share price.)This can inflate base share price as high as 1:1e18 early on, which force all subsequence deposit to use this share price as base.
Impact
New xERC4626 vault share price can be manipulated right after creation. Which give early depositor greater share portion of the vault during the first cycle.
While deposit token also affected by rounding precision (due to exploit above) that always return lesser amount of share for user.
POC
Add these code to
xERC4626Test.t.sol
file to test.Log Result:
Mitigate Recommendation
This exploit is unique to contract similar to ERC4626. It only works if starting supply equal 0 or very small number and rewards cycle is very short. Or everyone withdraws, total share supply become 0.
This can be easily fix by making sure someone always deposited first so
totalSupply
become high enough that this exploit become irrelevant. Unless in unlikely case someone made arbitrage bot watching vault factory contract. Just force deposit early token during vault construction as last resort.