code-423n4 / 2024-03-coinbase-findings

1 stars 0 forks source link

Paymaster can be Banned Due to Unmitigated Front-running Attacks on Bundled Transactions #164

Closed c4-bot-10 closed 3 months ago

c4-bot-10 commented 3 months ago

Lines of code

https://github.com/code-423n4/2024-03-coinbase/blob/main/src/MagicSpend/MagicSpend.sol#L109

Vulnerability details

Impact

A malicious user could potentially exploit certain conditions to cause functions like validatePaymasterUserOp to revert consistently. If these reverts happen frequently, it could lead to the paymaster being flagged, deprioritized by the EntryPoint, or even banned due to perceived unreliability.

Proof of Concept

A bad actor could say observe a pending transaction in the bundler mempool that will significantly reduce the paymaster's balance, for instance a large withdrawal by a legitimate user. Before this transaction is mined, the frontrunner executes another transaction that further depletes the contract's balance. This action could make the original transaction fail due to insufficient funds.

Github link

if (address(this).balance < withdrawAmount) {
            revert InsufficientBalance(withdrawAmount, address(this).balance);
        }

The EntryPoint relies on validatePaymasterUserOp to not revert under normal operation. Consistent reverts, especially due to balance issues caused by frontrunning, signal to the EntryPoint that the paymaster is unreliable.

Scenario

Front-runners monitor the mempool for transactions indicating significant balance changes or withdrawals from the paymaster. They then submit their transactions with higher gas fees which leads to their transactions being mined before the observed transactions.

This frontrunning can cause legitimate transactions to fail due to changed state conditions like insufficient balance, which in turn could cause validatePaymasterUserOp to revert consistently. Consequently signaling to Entrypoint that the paymaster is unreliable leading to it been banned or unprioritized for future transactions in the network.

Tools Used

Manual Review

Recommended Mitigation Steps

  1. Use private transaction relayers or services like Flashbots to prevent frontrunners from observing and exploiting transactions in the public mempool.

  2. Maintain a buffer of funds that are not immediately visible or accessible through withdrawal requests. This buffer can help ensure that observed transactions in the mempool do not lead to state changes that cause subsequent transactions to fail.

Assessed type

DoS

c4-pre-sort commented 3 months ago

raymondfam marked the issue as sufficient quality report

c4-pre-sort commented 3 months ago

raymondfam marked the issue as duplicate of #39

raymondfam commented 3 months ago

See #39.

c4-judge commented 3 months ago

3docSec changed the severity to 2 (Med Risk)

c4-judge commented 3 months ago

3docSec marked the issue as satisfactory