Open c4-submissions opened 1 year ago
raymondfam marked the issue as low quality report
raymondfam marked the issue as primary issue
Can't mint to address(0).
fatherGoose1 changed the severity to QA (Quality Assurance)
QA. Valid point, but this isn't technically stealing value from existing users. They will all benefit unexpectedly from the seizing of blacklisted funds. The fact that an arbitrageur can sandwich the call to redistributeLockedAmount()
does not impose any negative effects to user funds.
fatherGoose1 marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2023-10-ethena/blob/ee67d9b542642c9757a6b826c82d0cae60256509/contracts/StakedUSDe.sol#L148
Vulnerability details
Impact
The StakedUSDe contract has a redistributeLockedAmount function which enables the owner to redistribute the staked assets of a blocked account. This function has a
to
parameter which enables to chose an address to reallocate the assets to, otherwise this parameter can be set to 0 to redistribute the assets to the entirety of the stUSDe holders (as per name of the function). If the second option is utilized anyone can frontrun the redistributeLockedAmount call with a deposit, to get access to the assets redistribution, and immediately withdraw the deposited amount, basically accessing free yield, while decreasing the revenue for legit users.The protocol has a cooldown period after which a requested withdraw can be finalized; this parameter can be set to 0, in which case the malicious user will get access to the yield without any further inconvenience, otherwise they'll have to way for the cooldown period before being able to access the USDe tokens. During this period the assets will be stored in a silo contract, where, eventually only the withdraw requester can access them, there is no penalty or fee for doing so nor the assets will be available to the general protocol or to the owner account during the cooldown, meaning that a malicious user may be able to access to the yield by only exposing them self to the "risk" of not being able to trade or sell their USDe for a couple or day (since USDe is a stable coin this isn't particularly damaging)
Proof of Concept
The redistributeLockedAmount function can redistribute asset the the entirety of the stUSDe holders by setting the
to
parameters to 0 (as can be observed in the comment):Burning the shares, without changing the asset amount, will result in each stUSDe token holding more value.
This additional value, doesn't use the vesting period approach (used by the regular reward deposits, in transferInRewards), where tokens are released linearly over time, to prevent users from frontrunning the deposit of rewards and than withdrawing right away (See audit description). Since this counter measure is not taken by the redistributeLockedAmount function, any redistribution to the entire pool, can be frontrunned with a deposit, and back ran with a withdraw to get access to the yield, taking it from regular users of the protocol.
With the only inconvenience of the cooldown period, as mentioned in the
Impact
section above.Here is a foundry script that shows the over mentioned behavior. Place it the
/test/foundry/staking/
folder to preserve dependencies.Recommended Mitigation Steps
In case of a redistribution, the assets being released to the pool, could be added to the vestingAmount variable and released over time, as for other rewards.
Assessed type
Other