In src/contracts/core/StrategyManager.sol#L536 parameter indicesToSkip per documentation: """exists so that, e.g., if the slashed QueuedWithdrawal contains a malicious strategy in the strategies array which always reverts on calls to its 'withdraw' function, then the malicious strategy can be skipped (with the shares in effect "burned"), while the non-malicious strategies are still called as normal""".
However, the maliciuos strategies are not skipped because the loop index is incremented incorrectly, which allows one malicious strategy to effectively block withdrawal from all staker's strategies.
Proof of Concept
The following test (modified testSlashQueuedWithdrawalNotBeaconChainETH with non-empty indicesToSkip, added at src/test/unit/StrategyManagerUnit.t.sol#L1575) passes, although it should not:
Lines of code
https://github.com/code-423n4/2023-04-eigenlayer/blob/main/src/contracts/core/StrategyManager.sol#L536
Vulnerability details
Impact
In src/contracts/core/StrategyManager.sol#L536 parameter
indicesToSkip
per documentation: """exists so that, e.g., if the slashed QueuedWithdrawal contains a malicious strategy in the strategies array which always reverts on calls to its 'withdraw' function, then the malicious strategy can be skipped (with the shares in effect "burned"), while the non-malicious strategies are still called as normal""".However, the maliciuos strategies are not skipped because the loop index is incremented incorrectly, which allows one malicious strategy to effectively block withdrawal from all staker's strategies.
Proof of Concept
The following test (modified
testSlashQueuedWithdrawalNotBeaconChainETH
with non-emptyindicesToSkip
, added at src/test/unit/StrategyManagerUnit.t.sol#L1575) passes, although it should not:Recommended Mitigation Steps
Increment the loop index in every loop cycle:
Assessed type
Loop