Ecosystem - Colend Protocol - Coredao

The root cause of this known vulnerability is the loss of precision during smart contract operations, which can lead to price manipulation of the underlying assets.

Specifically, when a new market is activated in the lending protocol, there is a time window that can be exploited by an attacker. During this time window, the attacker can be the first individual to supply funds in the new market, manipulating the liquidityIndex, a key factor in determining user balances. The manipulation of the liquidityIndex allows the attacker to borrow all the underlying assets, resulting in a significant loss of funds.

- contracts/protocol/tokenization/base/ScaledBalanceTokenBase.sol [Lines: 99-120]

  function _burnScaled(address user, address target, uint256 amount, uint256 index) internal {
    uint256 amountScaled = amount.rayDiv(index);
    require(amountScaled != 0, Errors.INVALID_BURN_AMOUNT);

    uint256 scaledBalance = super.balanceOf(user);
    uint256 balanceIncrease = scaledBalance.rayMul(index) -
      scaledBalance.rayMul(_userState[user].additionalData);

    _userState[user].additionalData = index.toUint128();

    _burn(user, amountScaled.toUint128());

    if (balanceIncrease > amount) {
      uint256 amountToMint = balanceIncrease - amount;
      emit Transfer(address(0), user, amountToMint);
      emit Mint(user, user, amountToMint, balanceIncrease, index);
    } else {
      uint256 amountToBurn = amount - balanceIncrease;
      emit Transfer(user, address(0), amountToBurn);
      emit Burn(user, target, amountToBurn, balanceIncrease, index);
    }
  }

The vulnerability is further exacerbated by a known rounding issue in the rayDiv function, which is used to divide two ray values. The flaw in the rayDiv function can be taken advantage of to siphon funds from the pool, resulting in a cumulative precision loss that is magnified with repeated deposit and withdrawal operations.

- contracts/protocol/libraries/math/WadRayMath.sol [Lines: 83-92]

  function rayDiv(uint256 a, uint256 b) internal pure returns (uint256 c) {
    // to avoid overflow, a <= (type(uint256).max - halfB) / RAY
    assembly {
      if or(iszero(b), iszero(iszero(gt(a, div(sub(not(0), div(b, 2)), RAY))))) {
        revert(0, 0)
      }

      c := div(add(mul(a, RAY), div(b, 2)), b)
    }
  }

Consider minting minimum 1e6 token to the dead address.

ACKNOWLEDGED: The Colend team acknowledged the issue.

The current implementation of the AaveOracle contract relies on Pyth as the primary source of asset prices and falls back to a secondary oracle if the Pyth price is not available or inconsistent. However, this design may limit the flexibility and extensibility of the oracle system in the future, as it is tightly coupled with Pyth and the fallback oracle.

- contracts/misc/AaveOracle.sol [Lines: 101-114]

  /// @inheritdoc IPriceOracleGetter
  function getAssetPrice(address asset) public view override returns (uint256) {
    bytes32 priceFeedId = priceFeedIds[asset];

    if (asset == BASE_CURRENCY) return BASE_CURRENCY_UNIT;

    if (priceFeedId == 0) return 0;

    PythStructs.Price memory priceStruct = IPyth(ADDRESSES_PROVIDER.getPyth()).getPrice(
      priceFeedId
    );

    return uint256(uint64(priceStruct.price));
  }

It is recommended to introduce a more generic interface for price sources, allowing the integration of various oracle solutions beyond Chainlink and Pyth.

ACKNOWLEDGED: The Colend team acknowledged the issue.

On November 4th, 2023, Aave received a report through their bug bounty program about a high severity vulnerability affecting Aave v2, which was later upgraded to a critical severity. The vulnerability impacted some assets in Aave v2 on Ethereum and Aave v3 on Optimism, Arbitrum, Avalanche, and Polygon.

However, it has been discovered that the Colend protocol, did not disable the stable debt token minting functionality in their implementation. This leaves the Colend protocol potentially vulnerable to the same security issue that affected Aave.

- contracts/protocol/tokenization/StableDebtToken.sol [Lines: 123-175]

  /// @inheritdoc IStableDebtToken
  function mint(
    address user,
    address onBehalfOf,
    uint256 amount,
    uint256 rate
  ) external virtual override onlyPool returns (bool, uint256, uint256) {
    MintLocalVars memory vars;

    if (user != onBehalfOf) {
      _decreaseBorrowAllowance(onBehalfOf, user, amount);
    }

    (, uint256 currentBalance, uint256 balanceIncrease) = _calculateBalanceIncrease(onBehalfOf);

    vars.previousSupply = totalSupply();
    vars.currentAvgStableRate = _avgStableRate;
    vars.nextSupply = _totalSupply = vars.previousSupply + amount;

    vars.amountInRay = amount.wadToRay();

    vars.currentStableRate = _userState[onBehalfOf].additionalData;
    vars.nextStableRate = (vars.currentStableRate.rayMul(currentBalance.wadToRay()) +
      vars.amountInRay.rayMul(rate)).rayDiv((currentBalance + amount).wadToRay());

    _userState[onBehalfOf].additionalData = vars.nextStableRate.toUint128();

    //solium-disable-next-line
    _totalSupplyTimestamp = _timestamps[onBehalfOf] = uint40(block.timestamp);

    // Calculates the updated average stable rate
    vars.currentAvgStableRate = _avgStableRate = (
      (vars.currentAvgStableRate.rayMul(vars.previousSupply.wadToRay()) +
        rate.rayMul(vars.amountInRay)).rayDiv(vars.nextSupply.wadToRay())
    ).toUint128();

    uint256 amountToMint = amount + balanceIncrease;
    _mint(onBehalfOf, amountToMint, vars.previousSupply);

    emit Transfer(address(0), onBehalfOf, amountToMint);
    emit Mint(
      user,
      onBehalfOf,
      amountToMint,
      currentBalance,
      balanceIncrease,
      vars.nextStableRate,
      vars.currentAvgStableRate,
      vars.nextSupply
    );

    return (currentBalance == 0, vars.nextSupply, vars.currentAvgStableRate);
  }

To mitigate the risk and ensure the security of the Colend protocol, it is strongly recommended to disable the stable debt token minting functionality.

ACKNOWLEDGED: The Colend team acknowledged the issue.