Part 2

Summary

During initialization of dex-adapters, the contract is vulnerable to a denial-of-service (DoS) due to incorrectly handled access control. This potentially blocks the deployer from initializing these contracts when he is not the one passing his own address as owner.

Vulnerability Details

The initialize() functions in CurveAdapter, UniswapV2Adapter and UniswapV3dapter all take owner address as an input parameter. This may mean that the protocol intends to allow any deployer to be in a position to set any other protocol official other than themselves as the owner of these contracts during initialization.

Consider CurveAdapter:initialize():

Issue scenario:

Let's use the common function call in all of them: __BaseAdapter_init():

• Alice (deployer) calls initialize() on CurveAdapter passing Bob's address (another admin) as owner.

• This internal function takes the provided owner adress and passes it into __Ownable_init() which basically sets this address as the contract owner. Immediately, it invokes setSlippageTolerance():

• Notice that this function has the onlyOwner modifier which requires invokation only by the current contract owner.

• However, Alice is the caller but not the owner, Bob is. This initialization fails.

Impact

The current implementation will completely block the initialization flow when trying to set a different owner disrupting protocol deployment and setup processes.

Tools Used

Manual Review

Recommendations

If the intention of the protocol is to allow any deployer to set a diffrent address as owner, then create internal functions for the above owner controlled functions and invoke those created internal functions during initialization:
These owner controlled functions include:

• setSlippageTolerance()

• setCurveStrategyRouter()

• setUniswapV2SwapStrategyRouter()

• setUniswapV3SwapStrategyRouter()

• setPoolFee()