Closed c4-bot-8 closed 7 months ago
0xA5DF marked the issue as primary issue
These are cases where even if there's a slippage larger than expected, we want the txn to go through
0xA5DF changed the severity to QA (Quality Assurance)
Marking as low due to sponsor's comment
Moving credit to #82
0xA5DF marked the issue as grade-c
Lines of code
https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/Pool.sol#L411 https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/Pool.sol#L600
Vulnerability details
Impact
In Pool.sol, disabled slippage protection in reallocate flow putting undeployed funds at risk
Proof of Concept
In Pool.sol, when LidoEthBaseInterestAllocator.sol is set as getBaseInterestAllocator, slippage protection is disabled in multiple reallocate flows.
When the pool doesn't have enough capital, reallocation is needed to move funds from
getBaseInterestAllocator
to the pool throughIBaseInterestAllocator(getBaseInterestAllocator).reallocate()
, which takes in three parameters includingbool _force
, a toggle for slippage protection in LidoEthBaseInterestAllocator.sol.When
bool _force
is hard-coded to be true, slippage is turned off and allows any weth amount to be transferred to the pool without reverting. This might cause undeployed funds in allocator to be exploited in curve pool swap and resulting a loss.See below instances where _force is set to true: (1)
(https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/Pool.sol#L411)
(2)
(https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/Pool.sol#L600)
Tools Used
Manual
Recommended Mitigation Steps
Enable slippage protection.
Assessed type
Other