#38278 [BC-Low] Potential DoS to Mempool Due to Missing Gas Limit Check

Submitted on Dec 29th 2024 at 23:47:22 UTC by @CertiK for Attackathon | Ethereum Protocol

  • Report ID: #38278

  • Report Type: Blockchain/DLT

  • Report severity: Low

  • Target: https://github.com/ledgerwatch/erigon

  • Impacts:

    • (Specifications) A bug in specifications with no direct impact on client implementations

Description

Brief/Intro

The transaction validation misses the check of the gas limit in a transaction when entering the mempool (txpool). In case that the transaction of gas limit is more than the block gas limit, the transaction will never be included in a block, which should be discarded immediately.

However, the Erigon client misses such a check which allows these types of spam transactions to enter into the mempool. Since there is no cost to the attackers submitting such transactions, it would lead to the potential DoS attack to the Erigon mempool as it would consume a lot of computing resources.

Vulnerability Details

The transaction validation when entering the mempool (txpool) is performed within multiple functions:

  • ValidateSerializedTxn()

  • ValidateTx()

  • ParseTransaction()

However, there is no check on the gas limit in the transaction, which should be less than the block gas limit; Otherwise, it will never be mined to a block.

https://github.com/erigontech/erigon/blob/v3.0.0-alpha7/txnprovider/txpool/pool.go#L1037

https://github.com/erigontech/erigon/blob/v3.0.0-alpha7/txnprovider/txpool/pool.go#L815

https://github.com/erigontech/erigon/blob/34714c0c25cc59587240ae7abc1c2758315254af/txnprovider/txpool/pool_txn_parser.go#L125C29-L125C45

The Ergion mempool consists of a pending subpool, basefee subpool and queued subpool, which has the current default configuration that allows 10_000, 30_000, 30_000 transactions, respectively.

https://github.com/erigontech/erigon/blob/v3.0.0-alpha7/txnprovider/txpool/txpoolcfg/txpoolcfg.go#L66

A transaction could have at most 128KB, and ~800KB for blob transactions, the mempool could consume tens of gigabytes of memory and storage via submitting these spam transactions with more than block gas limit (30M). Since the gas limit could be set as large as possible, the transaction size can be close to the thresholds, 128KB and ~800KB for blob transactions.

https://github.com/erigontech/erigon/blob/34714c0c25cc59587240ae7abc1c2758315254af/txnprovider/txpool/pool.go#L1038C1-L1053C3

Though the txpool has some constraints to mitigate the spam transactions, for example, with 3 subpools and using nonce distance (gap), cumulative balance distance and timestamp as priority queue to discard transactions .

As the attack is costless, the attacker could submit numerous spam transactions of gas limit larger than block gas limit (30M) from different accounts.

Impact Details

Missing transaction gas limit check against the block gas limit would potentially lead to the DoS attack to Ergion mempool as it consumes a lot of computing resources without any cost to the attackers. These spam transactions will also be propagated to other Erigon nodes, which could possibly lead to a similar DoS attack.

References

  • https://github.com/erigontech/erigon/releases/tag/v3.0.0-alpha7

Proof of Concept

Proof of Concept

For simplicity, we spin up an Erigon dev chain according to the instructions, detailed in the documentation: https://github.com/erigontech/erigon/blob/release/2.60/DEV_CHAIN.md .

Note: the test does not demonstrate the worst scenario, as the tx size limit has not been reached and the blob transaction is not used.

  1. Submit spam transaction using Python web3 script with gas limit 300_000_000 (> block gas limit 30M):

  1. The log shows that the memory allocation jumps up to 100MB with 10 spam transactions,

  1. and eventually the txpool consumes around 3GB storage:

Was this helpful?