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

minDepositAmount should apply to asset and not share #351

Closed
code423n4 opened this issue Jan 18, 2023 · 2 comments
Closed

minDepositAmount should apply to asset and not share #351

code423n4 opened this issue Jan 18, 2023 · 2 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-486 edited-by-warden satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@code423n4
Copy link
Contributor

code423n4 commented Jan 18, 2023

Lines of code

https://github.com/AstariaXYZ/astaria-gpl/blob/4b49fe993d9b807fe68b3421ee7f2fe91267c9ef/src/ERC4626-Cloned.sol#L27

Vulnerability details

Impact

As asset and share are different things, the user may deposit the ASSET amount which is <= minDepositAmount IF ITS SHARE is > minDepositAmount.

Proof of Concept

See ERC4626-Cloned.sol

function deposit(uint256 assets, address receiver)
    public
    virtual
    returns (uint256 shares)
  {
    // Check for rounding error since we round down in previewDeposit.
    require((shares = previewDeposit(assets)) != 0, "ZERO_SHARES");

    require(shares > minDepositAmount(), "VALUE_TOO_SMALL");
    // Need to transfer before minting or ERC777s could reenter.
    ERC20(asset()).safeTransferFrom(msg.sender, address(this), assets);

    _mint(receiver, shares);

    emit Deposit(msg.sender, receiver, assets, shares);

    afterDeposit(assets, shares);
  }

In the deposit function above, the system checks if shares <= minDepositAmount(), if yes, revert the deposit

require(shares > minDepositAmount(), "VALUE_TOO_SMALL");

The system tries to compare shares against assets (Deposit amount). Assets and shares are related but they are completely different things. For example,

In a new empty vault, user A and user B make deposits

User A has 10 assets which are 10 shares
User B has 20 assets which are 20 shares

Here, the assets and shares are the same.

However, if the system withdraws 6 assets from the vault for some purpose

Total tokens = 24,
Total shares = 30,

In this case, the assets and shares are not the same

User A has 10 shares (which is 10 / 30 * 24 = 8 assets)
User B has 20 shares (which is 20 / 30 * 24 = 16 assets)

Let say,

If user C deposits 24 assets, he will get 30 shares [24 / (24 + 8 + 16) * (10 + 20 + 30)]

With the current code,

If minDepositAmount() = 25, his deposit will pass because 30 > 25. This is wrong because the deposit should fail as 24 < 25. We should verify by assets (NOT shares)

Tools Used

Manual

Recommended Mitigation Steps

Change the following code

function deposit(uint256 assets, address receiver)
    public
    virtual
    returns (uint256 shares)
  {
    // Check for rounding error since we round down in previewDeposit.
    require((shares = previewDeposit(assets)) != 0, "ZERO_SHARES");

    --- require(shares > minDepositAmount(), "VALUE_TOO_SMALL");
    +++ require(assets > minDepositAmount(), "VALUE_TOO_SMALL");
    // Need to transfer before minting or ERC777s could reenter.
    ERC20(asset()).safeTransferFrom(msg.sender, address(this), assets);

    _mint(receiver, shares);

    emit Deposit(msg.sender, receiver, assets, shares);

    afterDeposit(assets, shares);
  }
@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Jan 18, 2023
code423n4 added a commit that referenced this issue Jan 18, 2023
@c4-judge
Copy link
Contributor

Picodes marked the issue as duplicate of #486

@c4-judge
Copy link
Contributor

Picodes marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Feb 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-486 edited-by-warden satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants