Attacker will DoS LidoVault up to 36 days which will ruin expected apr for all parties involved
Summary
The parameters of each LidoVault are tuned such that fixed depositors get an upfront premium and variable depositors in return get all the yield produxed by the fixed depositors' deposits.
However, the protocol does not account for the fact that Lido may be DoSed for up to 36 days if it enters bunker mode. Assuming the return is 4% a year, users are losing approximately 4 * 36 / 365 == 0.4 %, which goes against the intended returns of the protocol.
Additionally, an attacker may forcefully trigger this by transferring only up to 100 wei of steth, which will make the protocol request an withdrawal and be on hold for 36 days.
The protocol should allow users to withdraw by swapping or similar, taking a much lower amount such as 0.12%, described here.
Root Cause
In LidoVault:712, anyone may transfer just 100 wei of steth and DoS the protocol, so fixed, variable and the owner can not withdraw their funds for up to 36 days.
Internal pre-conditions
None.
External pre-conditions
Lido enters bunker mode, which is in scope as it happens when a mass slashing event happens, which is in scope
The Lido Liquid Staking protocol can experience slashing incidents (such as this https://blog.lido.fi/post-mortem-launchnodes-slashing-incident/). These incidents will decrease income from deposits to the Lido Liquid Staking protocol and could decrease the stETH balance. The contract must be operational after it
Attack Path
Vault has already requested all withdrawals, but they have not yet been claimed, so funds are in the protocol but it does not hold stEth anymore.
Attacker transfers 100 wei of steth, triggering the request of this 100 steth.
All funds are DoSed for 36 days.
Impact
36 days DoS, which means the protocol can not get the expected interest rate calculated.
PoC
Look at the function LidoVault::vaultEndedWithdraw() for confirmation.
Mitigation
Firstly, an attacker should not be able to transfer 100 wei of steth and initiate a request because of this. The threshold should be computed based on an estimated earnings left to withdraw for variable depositors and fixed depositors that have not claimed, not just 100.
Secondly, it would be best if there was an alternative way to withdraw in case requests are taking too much.
0x73696d616f
Medium
Attacker will DoS
LidoVault
up to 36 days which will ruin expected apr for all parties involvedSummary
The parameters of each
LidoVault
are tuned such that fixed depositors get an upfront premium and variable depositors in return get all the yield produxed by the fixed depositors' deposits.However, the protocol does not account for the fact that Lido may be DoSed for up to 36 days if it enters bunker mode. Assuming the return is 4% a year, users are losing approximately
4 * 36 / 365 == 0.4 %
, which goes against the intended returns of the protocol.Additionally, an attacker may forcefully trigger this by transferring only up to 100 wei of steth, which will make the protocol request an withdrawal and be on hold for 36 days.
The protocol should allow users to withdraw by swapping or similar, taking a much lower amount such as 0.12%, described here.
Root Cause
In
LidoVault:712
, anyone may transfer just 100 wei of steth and DoS the protocol, so fixed, variable and the owner can not withdraw their funds for up to 36 days.Internal pre-conditions
None.
External pre-conditions
Lido enters bunker mode, which is in scope as it happens when a mass slashing event happens, which is in scope
Attack Path
Impact
36 days DoS, which means the protocol can not get the expected interest rate calculated.
PoC
Look at the function
LidoVault::vaultEndedWithdraw()
for confirmation.Mitigation
Firstly, an attacker should not be able to transfer 100 wei of steth and initiate a request because of this. The threshold should be computed based on an estimated earnings left to withdraw for variable depositors and fixed depositors that have not claimed, not just 100.
Secondly, it would be best if there was an alternative way to withdraw in case requests are taking too much.