Ethena Labs - supersizer0x's results

Lines of code

https://github.com/code-423n4/2023-10-ethena/blob/ee67d9b542642c9757a6b826c82d0cae60256509/contracts/StakedUSDeV2.sol#L100

Vulnerability details

Impact

By not checking if the user has cooldown already set int cooldownAssets and cooldownShares we can get out of your exisitng cooldown when a owner sets the cooldown lower.The reason this is an issue is because if some yield that still hasnt provided for the existing cooldown users then the protocol might not be able to service the users who now can unstake earlier.

Proof of Concept

ex:

1. Alice redeems sUSDE and at t0 cooldownDuation=14 days
2. Bob the owner sets the cooldownDuration=1 days
3. Alice redeems 1wei of sUSDE and its cooldown is now only 1 day
4. Alice now can redeem earlier causing the protocol either not to be able to handle so many unstaking requests or the protocol might give out to much yield or unfair amount of yield.

  if (assets > maxWithdraw(owner)) revert ExcessiveWithdrawAmount();

    uint256 shares = previewWithdraw(assets);

    cooldowns[owner].cooldownEnd = uint104(block.timestamp) + cooldownDuration;
    cooldowns[owner].underlyingAmount += assets;

    _withdraw(_msgSender(), address(silo), owner, assets, shares);

as we can see above their is no check that their is cooldown in progress so an attacker overide their cooldown

Tools Used

Recommended Mitigation Steps

require(cooldowns[owner].cooldownEnd!=0)

this below enables that they have to wait even longer

    cooldowns[owner].cooldownEnd = uint104(block.timestamp) + cooldownDuration + cooldowns[owner].cooldownEnd ;

Assessed type

Invalid Validation