The claimAndSwap function in the StrategyArb contract is vulnerable to a denial-of-service (DoS) attack. A malicious keeper can provide an excessively high _minOut value, causing the swap transaction to revert consistently. This prevents legitimate keepers from executing the intended function, effectively blocking the strategy's core functionality.
The claimAndSwap function is designed to allow keepers to claim WETH from the transmuter, swap it for alETH using a provided path on a router, and then deposit the acquired alETH back into the transmuter. The function includes a slippage check:
This check is intended to protect the strategy from receiving less alETH than expected due to price fluctuations during the swap. However, the function relies entirely on the keeper to provide the _minOut value. There is no upper bound or validation on this input.
PoC:
Assume the following scenario:
The strategy has a balance of WETH and alETH.
A keeper calls claimAndSwap.
The keeper sets _minOut to an extremely high value, for example, 10 times the expected output of the swap.
In this case, the _swapUnderlyingToAsset function will execute the swap. However, because _minOut is set artificially high, the require((balAfter - balBefore) >= _minOut, "Slippage too high"); check will always fail, causing the transaction to revert.
PoC values:
_amountClaim: 1 WETH (1 ether)
Expected alETH output (hypothetical): 1.01 alETH
_minOut: 10 alETH
In this case, the swap will likely return around 1.01 alETH. The check 1.01 >= 10 will fail, causing a revert.
The test will pass, demonstrating that the transaction reverts with the "Slippage too high" error when _minOut is set to an excessive value.
Legitimate keepers are unable to execute claimAndSwap, preventing the strategy from performing its core function of claiming and swapping WETH for alETH.
The strategy cannot capitalize on arbitrage opportunities or other profitable events that require the claimAndSwap function.
Manual review.
Instead of relying on the keeper's input for _minOut, calculate an acceptable slippage tolerance within the contract. This can be done by using a percentage-based slippage limit (e.g., 1% or 2%) or by using a price oracle to determine a more accurate minimum output.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.