😖Wrong Token Order In Return Value

Book an audit with Zokyo

TWAPOracle might register with wrong token order

Vulnerability Details

Issue:

The TWAPOracle.registerPair function is designed to take a factory and a pair of tokens (token0, token1). With the current setup, the function can accept any Uniswap-compatible factory as its argument. The issue arises when calling IUniswapV2Factory(factory).getPair(token0, token1), as this does not guarantee the order of token0 and token1; they might be reversed. This inconsistency in order affects the price0CumulativeLast and price1CumulativeLast values as well.

The code snippet below assumes that the internal order of price0CumulativeLast and price1CumulativeLast should match the order of function arguments token0 and token1:

javascriptCopy code_pairs.push(
    PairData({
        pair: pairAddr,
        token0: token0,
        token1: token1,
        price0CumulativeLast: price0CumulativeLast,
        price1CumulativeLast: price1CumulativeLast,
        blockTimestampLast: blockTimestampLast,
        price0Average: FixedPoint.uq112x112({_x: 0}),
        price1Average: FixedPoint.uq112x112({_x: 0})
    })
);

Impact:

This discrepancy can result in the oracle delivering inaccurate prices due to the potential inversion of the prices.

Recommended Mitigation Steps:

• Internal Order Verification: Validate if Uniswap's internal order of token0 and token1 matches the order provided as function arguments. If there is a mismatch, adjust the cumulative prices accordingly.

  Here's a pseudocode example for clarity:

  javascriptCopy codeIUniswapV2Pair pair = IUniswapV2Pair(
      IUniswapV2Factory(factory).getPair(token0, token1)
  );
  pairAddr = address(pair);
  price0CumulativeLast = pair.price0CumulativeLast();
  price1CumulativeLast = pair.price1CumulativeLast();
  
  // Adjust cumulative prices based on token order
  (price0CumulativeLast, price1CumulativeLast) = (token0 == pair.token0()) ? 
      (price0CumulativeLast, price1CumulativeLast) : 
      (price1CumulativeLast, price0CumulativeLast);

  With this adjustment, the cumulative prices are set accurately, regardless of the order in which tokens are provided in function arguments.

UniswapConfig getters return wrong token config if token config does not exist

Vulnerability Details

Issue Description:

The UniswapConfig.getTokenConfigBySymbolHash function is flawed due to a discrepancy in handling non-existent token configurations. The nested getSymbolHashIndex function returns 0 when there's no token configuration corresponding to the provided symbol hash (resulting from an uninitialized map value). However, the getTokenConfigBySymbolHash function incorrectly checks for non-existence using -1.

Similar issues occur with the following functions:

• getTokenConfigByCToken

• getTokenConfigByUnderlying

Impact:

This mismatch in non-existence checks leads the aforementioned functions to return the token configuration at the first index (index 0), even when there's no valid configuration for the requested token. Since index 0 holds valid configuration data for a different token, this error causes the system to provide incorrect oracle prices for tokens. In severe cases, this malfunction can be exploited, allowing users to borrow tokens at inaccurately low prices or to inflate the collateral value erroneously. As a result, users might initiate undercollateralized loans that are impermeable to liquidation, posing a serious risk to the platform's financial stability.

Recommended Mitigation Steps:

• Correct Non-Existence Check:

  • Adjust the non-existence check in the getTokenConfigBySymbolHash function (and other similarly affected functions) to align with the value returned by getSymbolHashIndex for non-existent configurations (which is 0).