Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Update of _totalCollateral(WETH) value in PerpetualAtlanticVaultLP.sol #730

Closed
code423n4 opened this issue Sep 1, 2023 · 2 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-867 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@code423n4
Copy link
Contributor

Lines of code

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

Vulnerability details

Impact

Whenever shares are redeemed in PerpetualAtlanticVaultLP, there's an accounting deficit that causes a revert in PerpetualAtlanticVaultLP.addProceeds(), leading to a denial of service in multiple functions that makes calls to PerpetualAtlanticVaultLP.addProceeds() through PerpetualAtlanticVault.updateFunding() like; PerpetualAtlanticVault.purchase(), PerpetualAtlanticVault.settle(), PerpetualAtlanticVaultLP.deposit(), and PerpetualAtlanticVaultLP.redeem()

Proof of Concept

  1. A user makes deposit to mint shares through PerpetualAtlanticVaultLP.deposit() where funds is transferred from user to the contract and _totalCollatera is updated(increamented). https://github.com/code-423n4/2023-08-dopex/blob/eb4d4a201b3a75dd4bddc74a34e9c42c71d0d12f/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L128-L132
 // Need to transfer before minting or ERC777s could reenter.
    collateral.transferFrom(msg.sender, address(this), assets);

    _mint(receiver, shares);

    _totalCollateral += assets;
  1. When shares are redeemed, funds(collateral and rpdx) are transferred to user, _rdpxCollateral is updated(decremented) but _totalCollateral is not. https://github.com/code-423n4/2023-08-dopex/blob/eb4d4a201b3a75dd4bddc74a34e9c42c71d0d12f/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L162-L175
 _rdpxCollateral -= rdpxAmount;

    beforeWithdraw(assets, shares);

    _burn(owner, shares);

    collateral.transfer(receiver, assets);

    IERC20WithBurn(rdpx).safeTransfer(receiver, rdpxAmount);

    emit Withdraw(msg.sender, receiver, owner, assets, shares);
  1. The problem here is, in PerpetualAtlanticVaultLP.addProceeds() a check is done to assert that balanceOf Collateral is equal or greater than _totalCollateral + proceeds, this will NEVER hold if shares have been redeemed. https://github.com/code-423n4/2023-08-dopex/blob/eb4d4a201b3a75dd4bddc74a34e9c42c71d0d12f/contracts/perp-vault/PerpetualAtlanticVaultLP.sol#L191-L194
require(
      collateral.balanceOf(address(this)) >= _totalCollateral + proceeds,
      "Not enough collateral token was sent"
    );

Instance:

--Alice makes a deposit of 100 collateral token to get equivalent shares, this increases _totalCollateral by 100.
--Alice redeems 50% of her shares to get 50 collateral token transferred back to her by the contract, reducing the contract balance by 50 but no corresponding decrease in _totalCollateral.
--So whenever collateral.balanceOf(address(this)) >= _totalCollateral + proceeds is checked, _totalCollateral will still hold 100+, so the check always fails.
--The ripple effect is that all function that relies on the check fails.

Tools Used

Manual review.

Recommended Mitigation Steps

Update _totalCollateral after transferring collateral to the redeemer.

_totalCollateral -= assets;

Assessed type

Token-Transfer

@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Sep 1, 2023
code423n4 added a commit that referenced this issue Sep 1, 2023
@c4-pre-sort
Copy link

bytes032 marked the issue as duplicate of #867

@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-867 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

3 participants