Skip to content

Latest commit

 

History

History
55 lines (44 loc) · 3.34 KB

034.md

File metadata and controls

55 lines (44 loc) · 3.34 KB

Careful Aegean Koala

High

Frontrunning attack in Vault contract

1. Description

The Vault contract is vulnerable to front-running attacks due to the following issues:

  1. Slippage Vulnerability in convertToShares and convertToAssets:

    • The functions convertToShares and convertToAssets calculate conversion rates using real-time ratios (totalAssets and totalShares) without implementing slippage protection.
    • These ratios are derived from the latest checkpoint (_checkpoints[_accounts[address(0)].read().latest]) and can be influenced by external factors, such as deposits or redemptions.
    • An attacker can monitor pending transactions and manipulate the checkpoint timing to alter the conversion rate temporarily, leading to unfavorable slippage for the victim.

  2. No Commit-Reveal Mechanism:

    • Actions like deposits, redemptions, and updates are executed in a single transaction without a commit-reveal scheme.
    • This makes sensitive operations vulnerable to sandwich attacks, where an attacker:
      1. Front-runs the user's transaction to manipulate the state (e.g., increase asset prices).
      2. Executes their own transaction to profit from the manipulated state.
      3. Back-runs the user's transaction to restore the original state.

2. Proof of Concept

  1. Slippage Manipulation:

    • Alice submits a transaction to deposit assets into the vault.
    • Bob, a malicious actor, detects Alice's pending transaction in the mempool.
    • Bob front-runs Alice's transaction by submitting a large deposit, which shifts the totalAssets and totalShares ratio.
    • Alice's transaction executes at an unfavorable rate due to the altered ratio.
    • Bob back-runs Alice's transaction by withdrawing his deposit, restoring the original state while profiting from the temporary manipulation.

  2. Sandwich Attack:

    • Alice submits a transaction to redeem shares from the vault.
    • Bob detects Alice's pending transaction and front-runs it by redeeming a large number of shares, causing the totalAssets to decrease.
    • Alice's transaction executes at a lower asset-per-share ratio, resulting in fewer assets received.
    • Bob back-runs Alice's transaction by re-depositing his redeemed assets, restoring the original state while profiting from the price difference.

Code:

function convertToShares(UFixed6 assets) external view returns (UFixed6) {
        (UFixed6 _totalAssets, UFixed6 _totalShares) =
            (UFixed6Lib.unsafeFrom(totalAssets()), totalShares());
        return _totalShares.isZero() ? assets : assets.muldiv(_totalShares, _totalAssets);
}

function convertToAssets(UFixed6 shares) external view returns (UFixed6) {
        (UFixed6 _totalAssets, UFixed6 _totalShares) =
            (UFixed6Lib.unsafeFrom(totalAssets()), totalShares());
        return _totalShares.isZero() ? shares : shares.muldiv(_totalAssets, _totalShares);
}

3. Impact

  • Financial Loss: Users may experience significant slippage or lose funds due to sandwich attacks.
  • Market Integrity: Manipulation of conversion rates undermines the fairness and reliability of the vault's operations.
  • Likelihood: High (Front-running is a well-documented and prevalent attack vector in DeFi).