The setRouter
function in StrategyOp.sol
and StrategyArb.sol
does not revoke the approval for the old router when changing to a new router. This oversight can lead to potential security vulnerabilities and incorrect accounting like draining of funds or wrong accounting if there are exploits on the previous router/routers
In the setRouter
function of the mentioned strategy contracts StrategyArb.sol::setRouter
, StrategyArb.sol::setRouter
, when the router address is updated, the old router remains approved to transfer tokens. This can result in the old router retaining the ability to transfer tokens, which poses a risk if the old router is compromised or exploited. The lack of revocation for the old router's approval can lead to unauthorized token transfers and incorrect accounting
A proof of concept for the attack is provided below. This can be added into a new test file under the test
folder.
The primary impact of this vulnerability includes:
Unauthorized Token Transfers: If the old router is compromised, it can still transfer tokens, leading to potential draining of funds.
Incorrect Accounting: The presence of multiple approved routers can lead to confusion and incorrect accounting of token transfers.
Security Risks: Exploits in the old router can be leveraged to manipulate token transfers, causing financial losses.
Manual code review.
To mitigate this vulnerability, add the following line of code to the setRouter
function in StrategyOp.sol
and StrategyArb.sol
to revoke the approval for the old router before setting the new router:
This ensures that the old router is no longer approved to transfer tokens.
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.