Dopex - AkshaySrivastav's results

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L201

Vulnerability details

Impact

The PerpetualAtlanticVaultLP.subtractLoss function contains this validation statement

  function subtractLoss(uint256 loss) public onlyPerpVault {
    require(
      collateral.balanceOf(address(this)) == _totalCollateral - loss,
      "Not enough collateral was sent out"
    );
    _totalCollateral -= loss;
  }

The function has a strict equality check for collateral token balance. Anyone can donate 1 wei to collateral token to the VaultLp contract and force this function to always revert.

Due to this the PerpetualAtlanticVault.settle function will also always revert. Hence no bond can be settled ever.

Proof of Concept

• In PerpetualAtlanticVaultLP, the collateral token balance and _totalCollateral is 100.
• An attacker donates 1 wei of collateral tokens to the contract.
• In the next settle call, the balance of VaultLp is reduced by 10 and subtractLoss is invoked. But now the token balance of contract is 91 (100 + 1 - 10) and _totalCollateral is 100.
• The require statement reverts as 91 != 100 - 10.
• PerpetualAtlanticVaultLP.subtractLoss reverts.
• PerpetualAtlanticVault.settle reverts.

Tools Used

Manual review

Recommended Mitigation Steps

Use >= operator instead of ==.

Assessed type

Context

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L159

Vulnerability details

Impact

Anyone can gain disproportionate amount of PerpetualAtlanticVaultLP shares instantly and can use them to drain almost all rDPX tokens from the contract.

The deposit function of PerpetualAtlanticVaultLP contract can be called by anyone. So anyone can deposit WETH and can collect vault shares. During redemption, the output WETH and rDPX amounts are calculated based upon the ratio of caller's shares balance and shares total supply.

  function _convertToAssets(
    uint256 shares
  ) internal view virtual returns (uint256 assets, uint256 rdpxAmount) {
    uint256 supply = totalSupply;
    return
      (supply == 0)
        ? (shares, 0)
        : (
          shares.mulDivDown(totalCollateral(), supply),
          shares.mulDivDown(_rdpxCollateral, supply)
        );
  }

So anyone with huge shares balance can withdraw almost all rDPX tokens from the contract instantly.

Proof of Concept

• The PerpetualAtlanticVaultLP contract contains 100 WETH and 1000 rDPX. Total supply of vault lp shares is 100e18.
• Attacker deposits 100,000 WETH to the vault and receives 100,000e18 vault shares.
• Attacker calls redeem and withdraws his 100,000 WETH and additional 999 rDPX tokens (100000 * 1000 / 100100).

A flash loan can be used to perform the above steps atomically and without any upfront capital.

Tools Used

Manual review

Recommended Mitigation Steps

Consider restricting the deposit function to Core contract only. Otherwise the economics of contracts will remain misaligned, in current state any depositor can withdraw more than the deposited amount instantly.

Assessed type

Context

Lines of code

https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L123-L125

Vulnerability details

Impact

The PerpetualAtlanticVaultLP.deposit function looks like this:

  function deposit(
    uint256 assets,
    address receiver
  ) public virtual returns (uint256 shares) {
    require((shares = previewDeposit(assets)) != 0, "ZERO_SHARES");
    perpetualAtlanticVault.updateFunding();
    ...
  }

It can be seen that the shares amount for the deposit is calculated before performing the perpetualAtlanticVault.updateFunding, which is incorrect.

The perpetualAtlanticVault.updateFunding function sends collateral tokens to the vaultLp contract and hence updates _totalCollateral value.

The incorrect execution order of the above mentioned statements causes loss of funds for the contract.

Proof of Concept

• Collateral tokens in vaultLp is 100 and supply is 100.
• An attacker observes that the next updateFunding call will send 10 tokens to vaultLp.
• Attacker invokes the deposit function with 100 as input. His shares is calculated as 100. After that updateFunding is executed and 10 collateral tokens get transferred to vaultLp.
• Attacker receives 100 shares tokens.
• Now the contract has 210 collateral tokens (100 + 10 + 100) and 200 shares supply.
• Instantly, the attacker calls redeem and receives back 105 collateral tokens.

The attack caused instant profit of 5 tokens to the attacker, profit can be increased by increasing the attacker deposit amount. If attacker deposits 10k tokens he can capture all the additional 10 tokens.

This bug also leads to a scenario in which two depositors receive different ratio of shares even when they deposit in the same block.

Tools Used

Manual review

Recommended Mitigation Steps

Calculate the shares after performing the updateFunding.

Assessed type

Context