In the StrategyOp
and StrategyArb
contracts, there is a management-specific function, setRouter
, responsible for updating the router address. This router facilitates routing keepers' deposits to optimize yield generation. However, a critical oversight exists: when a new router is set, approvals for the old router are not revoked.
This oversight exposes both strategies to severe vulnerabilities commonly seen in Web3, DeFi, and smart contracts, including unauthorized fund access, double spending, liquidity fragmentation, and fund loss.
The relevant functions are as follows:
StrategyOp::setRouter
:StrategyArb::setRouter
:Although these functions validate inputs through onlyManagement
, they fail to revoke approvals for the old router, leading to significant vulnerabilities.
Unauthorized Access to Funds:
If the old router retains approval to spend tokens, it can still withdraw funds from the protocol, even if it is no longer in use.
Example: If the old router is compromised or has a hidden vulnerability, an attacker can exploit it to drain funds from the protocol.
Malicious Exploits:
If the private keys for the old router are leaked or its smart contract is exploited, malicious actors could use the remaining approval to siphon funds without the protocol’s knowledge.
Accidental Transactions:
Users or automated systems might unintentionally interact with the old router, causing transactions to be routed incorrectly.
Impact: Funds may be deposited into deprecated or unintended contracts, leading to inefficiencies or potential loss.
Confusion in Asset Management:
Active approvals for multiple routers can create ambiguity about which router manages which assets, making audits and fund tracking more difficult.
Double Spending:
If both the old and new routers hold active approvals, assets could be inadvertently allocated to both strategies simultaneously. This could result in inconsistencies in the protocol's accounting and yield calculations.
Liquidity Fragmentation:
Tokens could remain locked in the old router if it still holds authorization but is no longer actively managed. This leads to reduced protocol efficiency and fragmentation of liquidity.
The failure to revoke old router approvals can result in:
Token Theft: Funds could be drained by malicious actors exploiting compromised routers.
Operational Failures: Incorrect or unintended routing of funds, causing disruptions in strategy execution.
Double Spending: Assets might be spent or allocated redundantly, compromising accounting integrity.
Liquidity Inefficiency: Tokens might remain stuck in obsolete routers, reducing capital efficiency.
This oversight significantly increases the security risk and operational fragility of the protocol.
Manual Review
To address this vulnerability, revoke approvals for the old router before assigning a new one. This ensures that the old router no longer has the authority to spend the protocol's tokens.
setRouter
Function:Prevents Unauthorized Access: The old router loses all approvals, eliminating risks of misuse or exploits.
Improves Security Hygiene: Minimizes the attack surface and mitigates potential fund mismanagement.
Ensures Operational Integrity: Ensures only the new router has the ability to manage tokens.
By implementing this safeguard, the protocol can significantly enhance its resilience and protect user funds from avoidable vulnerabilities.
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.