The claimAndSwap
function in StrategyMainnet
is vulnerable to reentrancy attacks due to multiple external calls (transmuter.claim
, router.exchange
, transmuter.deposit
) without safeguards. This allows attackers to exploit the function through reentrant calls, manipulating the contract state or draining funds. Mitigation requires reentrancy guards, improved function design, and restricted external interactions.
Technical Details
The function performs external calls to the transmuter
and router
without locking its state.
It checks balances (balBefore
and balAfter
) post-execution, making them susceptible to manipulation during reentrant calls.
Attack Scenarios
Setup:
An attacker sets a malicious router address via setRouter
(centralized risk).
Execution:
During router.exchange
, the malicious router re-enters claimAndSwap
via another transaction, triggering recursive execution.
Impact:
Funds are drained through repeated swaps.
Balance checks (balBefore
, balAfter
) are bypassed, making validation ineffective.
State Manipulation: Manipulated deposits disrupt accounting for user shares and yields.
Potential Denial of Service (DoS): Infinite loops could exhaust gas, disrupting operations.
Financial Loss: Draining funds from the contract through recursive execution.
Operational Disruption: Broken accounting due to manipulated balances.
Reputation Damage: Loss of trust in the protocol’s security.
Mitigation Recommendations
Reentrancy Guard:
Use OpenZeppelin’s ReentrancyGuard
to prevent reentrant calls.
Follow the Checks-Effects-Interactions Pattern:
Update contract state (e.g., balance deductions) before external calls:
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.