DYAD - Dinesh11G's results

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/VaultManagerV2.sol#L119 https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/VaultManagerV2.sol#L134

Vulnerability details

Impact

This vulnerability could lead to financial losses for users of the VaultManagerV2 contract, as attackers could exploit the timing of transactions to manipulate asset prices and gain profit at the expense of legitimate users.

1. An attacker monitors pending transactions on the blockchain involving the deposit or withdraw functions of the VaultManagerV2 contract.
2. When they detect a transaction that fits their criteria (e.g., large deposit or withdrawal), they quickly submit their own transaction with manipulated parameters to take advantage of the situation.
3. By adjusting the timing or parameters of their transaction, the attacker can manipulate asset prices and potentially profit from the price movements.

Proof of Concept

The VaultManagerV2 contract contains a front-running vulnerability in the VaultManagerV2::deposit and VaultManagerV2::withdraw functions, allowing attackers to manipulate transactions and potentially gain unfair advantage.

@>  function deposit(
    uint    id,
    address vault,
    uint    amount
  ) 
    external 
      isValidDNft(id)
  {
    idToBlockOfLastDeposit[id] = block.number;
    Vault _vault = Vault(vault);
    _vault.asset().safeTransferFrom(msg.sender, address(vault), amount);
    _vault.deposit(id, amount);
  }

  /// @inheritdoc IVaultManager
@>  function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
REMAINING CODE ....................

I discovered this issue in the following lines of code:

• Line 119 - deposit function
• Line 134 - withdraw function

Scenario:

Tools Used

VS code Manual review

Recommended Mitigation Steps with fix code

• To mitigate this vulnerability, consider implementing mechanisms such as transaction batching, fee-based priority ordering, or cryptographic commitments to prevent front-running attacks.

• Allow users to execute transactions privately and avoid the risk of being front-run by malicious actors.

Assessed type

MEV