Front-running Vulnerability in NativeVault Snapshot Process

[c4-bot-4]

Lines of code

https://github.com/code-423n4/2024-07-karak/blob/main/src/NativeVault.sol#L112

Vulnerability details

Intro

The NativeVault contract's snapshot process is vulnerable to a front-running attack that could be exploited by a malicious node owner. This vulnerability stems from the ability of any node owner to initiate a snapshot and the subsequent ability for anyone to submit validator proofs for that snapshot. This will lead to a myriad of issues like denial of service and griefing attacks.

Details

Attack Vector

A malicious node owner can affect pending snapshots of other users through the following mechanism:

1. Monitor the mempool for startSnapshot transactions from other node owners.
2. Front-run these transactions with their own startSnapshot call.
3. Quickly follow up with validateSnapshotProofs calls using manipulated proofs.

Impact

1. Snapshot Overwriting:

   • When a malicious actor front-runs a legitimate startSnapshot call, it overwrites the currentSnapshotTimestamp and currentSnapshot in the contract's state.
   • This effectively cancels the pending snapshot of the legitimate user, as the contract now considers the malicious actor's snapshot as the current one.

2. Proof Invalidation Dos:

   • The validateSnapshotProofs function checks against the currentSnapshotTimestamp:

if (validatorDetails.lastBalanceUpdateTimestamp >= node.currentSnapshotTimestamp) {
    revert ValidatorAlreadyProved();
}

• By setting a new currentSnapshotTimestamp, the attacker invalidates any proofs that legitimate users were preparing to submit for their own snapshots.

3. Balance Update Manipulation:

   • The attacker can submit manipulated proofs that misrepresent the balance changes of validators.
   • This affects the snapshot.balanceDeltaWei calculation, which directly impacts the balance updates for all users.

4. Griefing through Delayed Balance Updates:

• Legitimate users whose snapshots are overwritten will have to wait and attempt to start a new snapshot later.

• This delay could prevent timely recognition of balance changes, potentially leading to:

  • Delayed reward distributions
  • Inaccurate representation of user stakes
  • Misalignment with actual validator performances on the beacon chain

5. Incorrect Balance Calculations:

   • If the attacker successfully submits manipulated proofs, it could lead to:
   • Overstating of the attacker's balance increases
   • Understating of the attacker's balance decreases
   • Potential understating of other users' balance increases
   • Possible overstating of other users' balance decreases

6. Economic Losses:

   • Users might miss out on timely withdrawal opportunities due to understated balances.

Code Sections

https://github.com/code-423n4/2024-07-karak/blob/main/src/NativeVault.sol#L112

function startSnapshot(bool revertIfNoBalanceChange)
    external
    nonReentrant
    nodeExists(msg.sender)
    whenFunctionNotPaused(Constants.PAUSE_NATIVEVAULT_START_SNAPSHOT)
{
    _startSnapshot(_state().ownerToNode[msg.sender], revertIfNoBalanceChange, msg.sender);
}

function validateSnapshotProofs(
    address nodeOwner,
    BeaconProofs.BalanceProof[] calldata balanceProofs,
    BeaconProofs.BalanceContainer calldata balanceContainer
)
    external
    nonReentrant
    nodeExists(nodeOwner)
    whenFunctionNotPaused(Constants.PAUSE_NATIVEVAULT_VALIDATE_SNAPSHOT)
{

}

Recommendations

1. Replace the current snapshot system with a queue, where snapshot requests are processed in order.
2. Enforce a minimum time between snapshots for each node.
3. Implement a commit-reveal scheme for snapshot initiation to prevent front-running.

Assessed type

Other