Alchemix Transmuter

Summary

The strategy contracts grant unlimited ERC20 allowances to the router and permit the manager role to change the router address without restrictions. Since manager is authorized to update the router at will, an attacker who gains control of the manager role can set a malicious router contract, which then can freely pull all approved tokens from the strategy. This configuration bypasses any intended protections and could enable severe misuse of funds. While management roles are trusted, the lack of a whitelist or verification process for router addresses makes the system vulnerable if management keys are ever compromised. Additionally, the ability to add arbitrary swap routes without proper validation can lead to the router being used not only for draining funds, but also to disrupt yield operations indefinitely, compounding the overall risk.

Impact

• Immediate Asset Drain: With infinite approvals in place, an attacker who obtains management privileges can point the router to a malicious contract and instantly transfer out all of the strategy's underlying tokens.

• Denial of Service (DOS) on Yield Operations: Beyond outright theft, malicious route configurations can force swaps to revert or return zero tokens, preventing the strategy from realizing yield, thus undermining its core functionality.

• Erosion of Trust and Stability: Even if not directly drained, the threat of a compromised manager can create a hostile environment where the protocol’s invariants—asset integrity, access control, and premium enforcement—are threatened.

Vulnerability Details

Files & Relevant Code:

• StrategyOp.sol, StrategyMainnet.sol, StrategyArb.sol

The strategies set infinite allowances to the router upon initialization and whenever setRouter is called by the manager. There are no checks on the new router address, and no verification step to ensure that the router contract is legitimate.

Excerpts:

The above code shows that whenever setRouter is called, a new router address is provided and given unlimited token approval. If router is malicious, it can transferFrom the strategy’s balance immediately.

Similarly, adding new routes (addRoute in the Mainnet strategy) can specify arbitrary parameters that cause swaps to revert, effectively creating a persistent denial-of-service for the yield generation logic. With no validation of route endpoints or pools, a malicious manager can ensure that no profitable (or even possible) swap can occur.

Why This Occurs:

• Unlimited allowances grant full spending rights to the approved address.

• The manager role can arbitrarily set the router without any whitelisting or verification step.

• There's no enforced list of trusted routers or routes, allowing malicious configurations to remain undetected until exploited.

Proof of Concept (PoC)

1. Fund Drain Scenario:

   • Assume attacker compromises the manager role’s private key.

   • Attacker calls:

     strategy.setRouter(attackerControlledContract);

   • The strategy now approves attackerControlledContract with infinite underlying token allowance.

   • Attacker’s malicious router contract:

     // Pseudocode of malicious router:

     // Once the router is set, call `transferFrom` on `underlying`:

     underlying.transferFrom(address(strategy), attacker, strategyBalance);

   • All strategy funds are transferred to attacker, resulting in total asset loss.

2. Yield DOS Scenario:

   • With manager compromised, add a malicious route via:

     strategy.addRoute(_route, _swapParams, _pools); // parameters leading to revert

   • Now, every call to claimAndSwap that attempts to use this route will revert.

   • The strategy can no longer perform its main function: claiming and swapping to compound yields. Over time, this effectively neutralizes the strategy.

Tools

• Manual Review

Recommendations

1. Router Whitelisting:
   Introduce a whitelist of approved router addresses. The manager can only select from a pre-verified list of router contracts that have undergone security checks. This ensures that even if the manager role is compromised, the attacker cannot set an arbitrary malicious router.

2. Restricted Approvals:
   Instead of granting type(uint256).max approvals, consider setting allowances as needed or implementing a mechanism that requires explicit confirmation before reassigning a router. Reducing token allowances to 0 before switching routers could also help, ensuring there are no lingering full approvals.