First depositor can partially steal deposits and DoS vaults #393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue: #392
Severity
High
Description
This issue contains code logic from both
HATVault.solandERC4626Upgradeable.solwhich is an abstract contract inherited byHATVault.sol. The first vault's depositor is able to compromise vaults by minting a minimum amount of shares (such as 1 wei of the staking token) and transferring a much larger amount further on (1 ether worth of staking tokens, or 1e18). This makes it sosupplyinERC4626Upgradeable.solwill be 1, whiletotalAssets()will return1e18. This makes the share price extremely overvalued, and every future deposit below the transferred amount will revert due toconvertToShares()returning 0.Deposit with amounts above this amount transferred by the malicious actor will proceed, however due to rounding issues, the depositor . In the example below, the code has the first malicious actor transferring
1e18stakingToken amount, a second clueless actor depositing1.5e18tokens will only receive 1 share. Since the total token amount is2.5e18tokens, 1 share will be able to withdraw1.25e18tokens, so the first depositor can exit with a stolen profit of0.25e18.Mitigation
Uniswap V2 faced the same vulnerability, and fixed it by automatically minting 1000 shares and sending it to address zero. You can check the code snippet here. For this project, I recommend sending those 1000 shares to address(0) in the
HATVault.solinitializer.