Bug Report: Denial of Nethermind's Txpool Service by Latent Invalid Transactions (Z)

[mous314anony]

Bug Report: Denial of Ethereum Txpool Service by Latent Invalid Transactions (Z)

• Time: Jun 25, 2021
• (We didn't find a bug bounty program or a place to report security bugs on nethermind, so post it here).

Summary

The attacker node can send crafted invalid transactions to a victim Nethermind node to purge all pending transactions in its txpool and make the victim node's miner read zero or very few transactions. This attack incurs little Gas per block.

The root cause of this attack is that what we call latent invalid transactions submitted to a txpool can evict the valid pending transactions there. For instance, sending three transactions tx1, tx2, tx3 of the same sender s, each spending the full balance s to a txpool. These three transactions at high Gas price are admitted to txpool, potentially evicting other transactions in txpool. However, tx2 and tx3 are overdrafts and will be invalidated by miners, making their (high) Gas price uncollectible.

In the mitigation scheme, the txpool should limit the number of the exploited evictions, namely the evictions of valid pending transactions by invalid transactions.

Background

Consider txpool on one node receives a message that contains multiple transactions from a remote node. Assume the current size of txpool reaches 1024. The txpool will select the one from existing transactions that bids the lowest Gas price and compare its Gas price with the newly received one. If the new transaction bids a higher Gas price, the selected one will be evicted. Besides, the number of transactions that belong to the same account cannot exceed 17.

Since any neighbors can send a message that contains many transactions to a victim node, a malicious node can use 61 accounts to prepare 1024 transactions with each of them fully transfer the sender's balance and bids extremely high Gas price, then the malicious node can wrap them up in one message and send it to a victim Nethermind node. In all of the transactions, only the first pending transaction of each account is valid, the rest of them are invalid and overdraft. On the victim node, when receiving such 1024 transactions that fully transferred their sender's balance and processing them in txpool, it will evict all of the existing transactions (including pending and future transactions). Since invalid transactions will not be propagated or included by the miner, only one transaction(the first pending transaction) of each account will be included in blocks. The cost of this attack is 0.021 * 61 = 1.281 Ether.

One can exploit this vulnerability to attack the mining nodes in the mainnet and testnets and cause the block mined by them includes very few transactions.

Technical details

The attack works by sending one message with crafted 1024 invalid transactions (with high Gas price, e.g., 1000 Gwei) to a victim mining node, such 1024 invalid transactions can purge all of the existing transactions in the victim node's txpool (including both pending and future transactions). The root cause is that when adding a new transaction into txpool, an overdraft transaction with a higher Gas price can evict an existing pending transaction with a lower Gas price.

More specifically, the attack works as follows.

1. The attacker owns 61 accounts with x Ether (x > 0.021).
2. The attacker runs an instrumented Ethereum client (e.g., Geth) and connects the node with a victim Nethermind node.
3. The attacker node prepares 1024 crafted invalid transactions with a high Gas price. For example, assume each transaction transfers (x - Gas * Gas Price) Ether to a target account and sets the Gas price to be 1000 Gwei and Gas to be 21000.
4. The attacker node sends all 1024 invalid transactions in one message to the victim Nethermind node at a low rate (e.g., 2 messages per second).

Proof of Concept

You can verify this by running three nodes in a private network with three nodes, a normal node that generates regular pending transactions, a victim Nethermind node, and an attacker node.

1. The normal node generates 1024 regular pending transactions
2. The attacker node sends attack payload (1024 invalid transactions) to the victim node
3. Then checking the content of txpool. There is no regular pending transaction left in the txpool. The txpool is fully occupied by 17 pending transactions from attacker's accounts and overdraft transactions.

Mitigation

To mitigate such a DoS attack, we propose the following defensive schemes.

1. Defense 1 is to further limit the number of transactions of the same sender in a txpool. This defends against the attack but also causes false positives. For instance, if a legitimate sender sends multiple full-spending transactions and other accounts refill the account, such a sequence of transactions in the same block will be declined.
2. Defense 2 is to decline overdraft transactions using the pending state. That is, consider transaction sequence tx1, tx2, and tx3. When admitting each transaction, the transaction validity will be checked against the state of all pending transactions and confirmed transactions. Hence, tx2 that spends an account balance that is already fully spent by tx1 will be invalidated.
3. Defense 3 is to remove the interference between invalid and valid transactions in the txpool. txpool can admit a future or invalid transaction if it does not trigger eviction. This defense policy only adds a restriction to a txpool eviction event. It prohibits any eviction that admits a future or invalid transaction and evicts a valid pending transaction. Besides, This defense policy prohibits any eviction that evicts a valid transaction and transforms another existing transaction into a future or invalid one.

[mous314anony]

Also, pls inform if there is a bug bounty program for nethermind.

[tkstanczak]

@matilote is in the process of setting up a bug bounty now

[tkstanczak]

@mous314anony you can send an email to tomasz@nethermind.io so we can retroactively contribute and discuss any future reports

[mous314anony]

Agreed, we can move the discussion to email.

[tkstanczak]

@marcindsobczak what is the state of this one?

[marcindsobczak]

PR is waiting for approve and merge (or request for changes)