EXPLOITABLE VULNERABILITY IN FIRST ASSET SUPPLY IMPACTING VTOKEN CALCULATIONS #462
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
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-220
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L743-L791
https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L800-L871
https://github.com/code-423n4/2023-05-venus/blob/main/contracts/VToken.sol#L1463-L1482
Vulnerability details
Impact
A serious vulnerability has been identified in the
VToken
contract within the Venus protocol. This vulnerability, stemming from an exploit in the initial supply of asset tokens, allows for manipulation of theexchangeRate
, potentially leading to profitable exploits at the expense of subsequent users. This is typically seen in share-based liquidity pools or vault contracts where the first investor can manipulate the price per share, thereby profiting from the next deposit due to precision loss induced by the inflated value of the price per share.The vulnerability lies in the fact that the first investor has the potential to maliciously manipulate the
exchangeRate
by supplying the smallest feasible amount of the asset, thereby artificially inflating theexchangeRate
. Specifically, because of the default rounding down associated with division truncation, this initial deposit could be tailored to front-run someone trying to make the first mint, thereby maximizing the profitability of the exploit.Proof of Concept
Here's a typical exploit scenario, assuming
initialExchangeRateMantissa = 1e18
(as assigned in TokenTestHelpers.ts) andtotalBorrows
,badDebt
andtotalReserves
remain in their defaulted zeros values:AlEX, a user, wishes to supply 1000e18 DAI to an empty VToken contract using DAI (compliant with 18 decimals) as its asset token.
Observing this transaction in the mempool, Lori, an attacker, decides to front-run it by depositing an initial liquidity of 1 wei DAI via
mint()
. This results in an exchange rate of 1:1 for wei vToken to wei DAI.Lori then artificially inflates the asset token balance by transferring 1000e18 DAI directly to the VToken contract without minting any new vToken.
The exchange rate is now 1 wei vToken per (1000e18 + 1) DAI.
Alex's deposit of 1000e18 DAI goes through, but due to precision loss, she receives 0 vToken and effectively loses her entire fund.
Lori could repeat this process with other victims, waiting for more deposits of assets less than _getCashPrior(), to receive 0 vToken like Alex, until she decides to call redeem() and receive all the underlying DAI.
Recommended Mitigation Steps
To mitigate this vulnerability, consider implementing the Uniswap V2 protocol's approach of sending the first 1000 wei of vToken to address 0 when
_totalSupply == 0
.Apart from that, a minimum deposit amount could also be established to prevent an attacker from manipulating the exchange rate by depositing a minimal amount of DAI. The limit should be set sufficiently high to prevent inflation of the
exchangeRate
to an extent that would cause precision issues.Furthermore, the protocol could explore the implementation of slippage protection measures to further safeguard against such scenarios.
Assessed type
ERC4626
The text was updated successfully, but these errors were encountered: