Manipulate the price per share value and unfair share of future users' deposits' #135
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-275
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/AutoPxGlp.sol#L142-L144
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/AutoPxGmx.sol#L164-L166
Vulnerability details
Impact
Most of the share based vault implementation will face this issue. The vault is based on the
ERC4626
where the shares are calculated based on the deposit value. By depositing large amount as initial deposit, initial depositor can influence the future depositors value. Future depositors are forced for huge value of asset to deposit. It is not practically possible for all the users. This could directly affect on the attrition of users towards this system.https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/AutoPxGlp.sol#L142-L144
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/AutoPxGmx.sol#L164-L166
Proof of Concept
The attacker can profit from future users' deposits. While the late users will lose part of their funds to the attacker.
A malicious early user can deposit() with 1 wei of asset token as the first depositor of the AutoRoller token, and get 1 wei of shares.
Then the attacker can send 10000e18 - 1 of asset tokens and inflate the price per share from 1.0000 to an extreme value of 1.0000e22 ( from (1 + 10000e18 - 1) / 1) .
As a result, the future user who deposits 19999e18 will only receive 1 wei (from 19999e18 * 1 / 10000e18) of shares token.
They will immediately lose 9999e18 or half of their deposits if they redeem() right after the deposit().
ERC4626 implementation function mint(uint256 shares, address receiver) public virtual returns (uint256 assets) { assets = previewMint(shares); // No need to check for rounding error, previewMint rounds up.
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/PirexERC4626.sol#L60-L78
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/PirexERC4626.sol#L80-L97
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/PirexERC4626.sol#L156-L165
https://github.com/code-423n4/2022-11-redactedcartel/blob/03b71a8d395c02324cb9fdaf92401357da5b19d1/src/vaults/PirexERC4626.sol#L178-L185
Tools Used
Manual Review
Recommended Mitigation Steps
Consider requiring a minimal amount of share tokens to be minted for the first minter, and send a portion of the initial mints as a reserve to the DAO/ burn so that the price per share can be more resistant to manipulation.
@Audit info
// for the first mint, we require the mint amount > (10 ** decimals) / 100
// and send (10 ** decimals) / 1_000_000 of the initial supply as a reserve to DAO
if (totalSupply == 0 && decimals >= 6) {
require(shares > 10 ** (decimals - 2));
uint256 reserveShares = 10 ** (decimals - 6);
_mint(DAO, reserveShares);
shares -= reserveShares;
}
@Audit info
// for the first mint, we require the mint amount > (10 ** decimals) / 100
// and send (10 ** decimals) / 1_000_000 of the initial supply as a reserve to DAO
if (totalSupply == 0 && decimals >= 6) {
require(shares > 10 ** (decimals - 2));
uint256 reserveShares = 10 ** (decimals - 6);
_mint(DAO, reserveShares);
shares -= reserveShares;
}
The text was updated successfully, but these errors were encountered: